TRIBUNAL DE CONTAS DA UNIÃO

Secretaria-Geral de Controle Externo

Secretaria de Auditoria e Inspeções

MANUAL DE AUDITORIA DE SISTEMAS

Brasília, setembro de 1998.

TRIBUNAL DE CONTAS DA UNIÃO

Presidente:
Ministro Homero Santos

Vice-Presidente:
Ministro Iram de Almeida Saraiva

Ministros:
Adhemar Paladini Ghisi
Carlos Átila Álvares da Silva
Marcos Vinicios Rodrigues Vilaça
Humberto Guimarães Souto
Bento José Bugarin
Antônio Valmir Campelo Bezerra

Auditores:
José Antônio Barreto de Macedo
Lincoln Magalhães da Rocha
Benjamin Zymler

Procurador-Geral:
Walton Alencar Rodrigues

Subprocuradores-Gerais:
Jatir Batista da Cunha
Lucas Rocha Furtado
Paulo Soares Bugarin

Procuradores:
Maria Alzira Ferreira
Marinus Eduardo Vries Marsico
Ubaldo Alves Caldas
Cristina Machado da Costa e Silva

Comissão Permanente de Regimento:

Ministro Adhemar Paladini Ghisi (Presidente)
Ministro Humberto Guimarães Souto (Membro)
Ministro Antônio Valmir Campelo Bezerra (Membro)
Auditor José Antônio Barreto de Macedo (Suplente)

Comissão Permanente de Jurisprudência:

Ministro Carlos Átila Álvares da Silva (Presidente)
Ministro Marcos Vinicios Rodrigues Vilaça (Membro)
 TRIBUNAL DE CONTAS DA UNIÃO
Secretaria-Geral de Controle Externo
Secretaria de Auditoria e Inspeções

MANUAL DE AUDITORIA DE SISTEMAS

Brasília, setembro de 1998.

Tribunal de Contas da União
Internet: http://www.tcu.gov.br

SAFS Lt. 01
CEP: 70.042-900 - Brasília (DF)

Secretário-Geral de Controle Externo:

José Nagel

Secretário de Auditoria e Inspeções:

Cláudio Souza Castello Branco

Diretor de Informações para Planejamento e Execução de Auditorias:

André Luiz Furtado Pacheco

Chefe do Serviço de Avaliação de Sistemas de Administração Pública

Daniel Dias Pereira

Analistas de Finanças e Controle Externo - Área de Controle Externo:

Adriana de Oliveira Beal (PDTI)

Cláudia Augusto Dias
Roberta Ribeiro de Queiroz Martins

657.6:681.3 Brasil. Tribunal de Contas da União

B823m Manual de Auditoria de Sistemas /
Tribunal de Contas da União. –
Brasília: TCU, Secretaria de Auditoria
e Inspeções, 1998.
107p.
Conteúdo: Portaria n. 455-GP, de
30 de setembro de 1998.

1. TCU - Manual de Auditoria de

Sistemas. 2. Auditoria de Sistemas.
I. Título

Ficha Catalográfica elaborada pela Divisão de Documentação do TCU.

 Portaria nº 455, de 30 de setembro de 1998.

Aprova o Manual de Auditoria de

Sistemas do Tribunal de Contas da
União.

O PRESIDENTE DO TRIBUNAL DE CONTAS DA UNIÃO, no uso de suas

atribuições legais e regimentais e tendo em vista o disposto no artigo 35 da Instrução
Normativa nº 09, de 16 de fevereiro de 1995, resolve:

Art. 1º Fica aprovado o Manual de Auditoria de Sistemas do Tribunal de Contas

da União, contendo os procedimentos operacionais e as estratégias metodológicas a serem
utilizadas na realização de auditorias de sistemas.

Art. 2º Esta Portaria entra em vigor na data de sua publicação.

HOMERO SANTOS
APRESENTAÇÃO

Um número cada vez maior de sistemas computacionais controla operações de

grande relevância no contexto das organizações, tornando imperativa a preparação do TCU
para enfrentar o desafio de auditar uma Administração Pública cada vez mais informatizada.

A utilização da tecnologia da informação para a manipulação e armazenamento

de dados nos órgãos auditados introduz novos riscos para o controle externo,
acrescentando outras variáveis às questões relacionadas ao planejamento e execução de
atividades de fiscalização.

Com o objetivo de aperfeiçoar as atividades de auditoria desenvolvidas pelo

corpo técnico do Tribunal, enfrentando a dificuldade de se auditar entidades com alto grau
de informatização, instituí, em 18 de agosto de 1997, um Grupo de Trabalho com o objetivo
de desenvolver e incrementar a aplicação da tecnologia da informação às atividades de
fiscalização no âmbito do TCU.

Este manual, desenvolvido pela Secretaria de Auditoria e Inspeções - SAUDI e

pelos componentes do mencionado Grupo de Trabalho, é fruto deste esforço de dotar o
TCU dos instrumentos necessários à modernização de sua atividade fiscalizatória.

Homero Santos
Presidente
 SUMÁRIO

Página

LISTA DE QUADROS................................................................................................ 12

LISTA DE SIGLAS..................................................................................................... 13

INTRODUÇÃO........................................................................................................... 14

PARTE 1 - TECNOLOGIA DA INFORMAÇÃO E ATIVIDADE DE FISCALIZAÇÃO -

AVALIAÇÃO DA CONFIABILIDADE DE DADOS PROCESSADOS POR
COMPUTADOR

1. REQUISITOS PARA A UTILIZAÇÃO DE EVIDÊNCIA PROVENIENTE DE DADOS

PROCESSADOS POR COMPUTADOR.......................................................................... 16

2. MÉTODOS DE AVALIAÇÃO DE DADOS PROCESSADOS POR COMPUTADOR........ 17

3. TÉCNICAS E PROCEDIMENTOS DE AVALIAÇÃO LIMITADA DA CONFIABILIDADE

DOS DADOS................................................................................................................... 18
3.1. Determinação do uso dos dados.................................................................... 18
3.2. Determinação dos dados que deverão ter sua confiabilidade avaliada......... 19
3.3. Levantamento do conhecimento prévio sobre os sistema e/ou os dados...... 20
3.4. Avaliação dos controles do sistema de processamento dos dados............... 20
3.4.1.Indícios de ineficácia dos controles de sistema.................................... 21
3.4.2.Parecer sobre a eficácia dos controles de sistema............................... 22
3.5. Determinação do risco de confiabilidade dos dados...................................... 22
3.6. Teste de dados............................................................................................... 24
3.6.1.Auditoria sem o auxílio do computador................................................. 24
3.6.2.Confrontação dos dados de entrada e saída do computador com
fontes independentes............................................................................ 25
3.6.3.Duplicação manual dos processos executados pelo computador......... 25
3.6.4.Verificações ditadas pelo senso comum............................................... 25
3.6.5.Observações sobre o uso da auditoria sem o auxílio do computador.. 26
3.6.6.Auditoria com o auxílio do computador................................................. 26
3.7. Divulgação da fonte dos dados e da confiabilidade atribuída aos mesmos.. 27
3.7.1.Papéis de trabalho................................................................................ 27
3.7.2.Informações que devem constar do relatório........................................ 27
3.7.3.Modelos a serem utilizados nos relatórios............................................ 28

4. ROTEIRO PARA AVALIAÇÃO DOS CONTROLES DE SISTEMA.................................. 29

7
 4.1. Controles gerais............................................................................................. 29
4.1.1.Controles organizacionais.................................................................... 29
4.1.2.Controles de projeto, desenvolvimento e modificação de
sistemas................................................................................................ 30
4.1.3. Controles de segurança....................................................................... 31
4.2. Controles aplicativos...................................................................................... 31
4.2.1. Controles da entrada de dados............................................................ 31
4.2.2. Controles de processamento de dados................................................ 32
4.2.3. Controles da saída de dados............................................................... 32
4.3. Avaliação extensiva dos controles de sistema............................................... 33
4.4. Avaliação moderada dos controles de sistema.............................................. 34
4.5. Avaliação reduzida dos controles de sistema................................................ 34

5. ESTUDO DE CASO......................................................................................................... 35
5.1. Situação hipotética......................................................................................... 35
5.2. Informações básicas sobre a área auditada................................................... 35
5.3. Procedimentos de avaliação.......................................................................... 35
5.4. Determinação do uso planejado para os dados............................................. 35
5.5. Levantamento dos elementos de conhecimento prévio sobre os dados e o
sistema............................................................................................................ 36
5.6. Avaliação dos controles do sistema............................................................... 36
5.6.1. Avaliação extensiva.............................................................................. 37
5.6.2. Avaliação moderada.............................................................................. 37
5.7. Determinação da confiabilidade de dados..................................................... 37
5.8. Teste de dados............................................................................................... 37
5.8.1. Teste extensivo..................................................................................... 37
5.8.2. Teste reduzido...................................................................................... 39
5.9. Conclusão....................................................................................................... 39

PARTE 2 - AUDITORIA DE SISTEMAS DE INFORMAÇÃO

1. CONTROLES GERAIS ......................................................................................... 41

1.1. Controles Organizacionais................................................................................. 43

1.1.1. Organização do departamento de tecnologia da informação .................... 43
1.1.2. Segregação das funções............................................................................ 43
1.1.3. Unidades organizacionais bem definidas................................................... 44
1.1.4. Atividades dos funcionários controladas e políticas claras de
seleção, treinamento e avaliação de desempenho........................................ 45
1.1.5. Política de segregação de funções e controles de acesso......................... 46
1.1.6. Recursos computacionais gerenciados de forma eficiente e econômica .. 47
1.2. Programa Geral de Segurança...................................................................... 48
1.2.1. Princípios da gestão da segurança............................................................. 48
8
 1.2.2. Avaliação do risco....................................................................................... 48
1.2.3. Estrutura de segurança............................................................................... 49
1.2.4. Avaliação periódica do risco........................................................................ 50
1.2.5. Documentação do programa de 50
segurança.................................................
1.2.6. Estrutura de gerência de Segurança com atribuição clara de
responsabilidade............................................................................................ 50
1.2.7. Políticas de segurança eficazes.................................................................. 51
1.2.8. Supervisão da eficácia do programa de segurança ................................... 51
1.3. Continuidade do Serviço ............................................................................... 52
1.3.1. Avaliação da vulnerabilidade das operações computadorizadas e
identificação dos recursos que os apoiam.................................................. 53
1.3.2. Adoção de medidas para prevenir e minimizar danos e interrupções
potenciais.................................................................................................... 53
1.3.2.1. Procedimentos de cópia de Segurança 53
(backup)..............................
1.3.2.2. Controles de ambiente...................................................................... 53
1.3.2.3. Treinamento do pessoal para responder a emergências................. 53
1.3.2.4. Medidas de prevenção de interrupções inesperadas....................... 54
1.3.3. Desenvolvimento e documentação de um plano geral de
contingência................................................................................................ 54
1.3.3.1. Documentação do plano de contingência......................................... 54
1.3.3.2. Alternativas de processamento de dados e telecomunicação ........ 55
1.3.3.3. Teste periódico do plano de contingência e realização dos ajustes
apropriados ..................................................................................... 55
1.4. Controles de Acesso........................................................................................... 55
1.4.1. Classificação dos recursos de informação de acordo com sua
importância e vulnerabilidade .................................................................... 57
1.4.2. Manutenção de lista atualizada de usuários autorizados e seu nível de
acesso......................................................................................................... 57
1.4.3. Implantação de controles lógicos e físicos para prevenção ou detecção
de acesso não autorizado........................................................................... 58
1.4.3.1. Controles lógicos sobre arquivos de dados e programas de
software 60
1.4.3.2. Controles lógicos sobre a base de dados ........................................ 60
1.4.3.3. Controles lógicos sobre acesso remoto............................................ 60
1.4.4. Supervisão do acesso, investigação de indícios de violação de
segurança e adoção das medidas corretivas ............................................ 61
1.5. Controles de Software de Sistema............................................................... 62
1.5.1. Acesso limitado ao software de sistema..................................................... 63
1.5.1.1. Caminhos de 63
acesso.........................................................................
1.5.2. Acesso e uso supervisionado do software de sistema .............................. 63
1.5.3. Controle das alterações do software de sistema........................................ 64
1.5.3.1. Instalação do software de sistema.................................................... 64

1.6. Controles de Desenvolvimento e Alteração de softwares aplicativos................ 65

9
 1.6.1. Características de processamento e modificações no programa são
devidamente autorizadas............................................................................ 65
1.6.2. Todos os softwares novos ou revisados são testados e aprovados........... 66
1.6.2.1. Alterações de emergência................................................................ 67
1.6.3. Bibliotecas de controle do software............................................................ 67
1.6.3.1. Identificação e inventário de programas........................................... 67
1.6.3.2. Restrições de aceso à biblioteca...................................................... 67
1.6.3.3. Controle do movimento de programas e dados entre bibliotecas .... 67

2. CONTROLES DE APLICATIVOS.......................................................................... 68
2.1. Controles da Entrada de Dados...................................................................... 68
2.1.1. Documentos ou telas de entradas de dados 68
............................................
2.1.2. Rotinas de preparação dos dados (batch)................................................ 69
2.1.3. Autorização para entrada de dados.......................................................... 69
2.1.4. Retenção de documentos de entrada (sistema batch)............................. 70
2.1.5. Validação dos dados de entrada.............................................................. 70
2.1.6. Tratamento de erros................................................................................. 71
2.1.7. Mecanismos de suporte para entrada de dados....................................... 72
2.2. Controles do Processamento de Dados.................................................... 72
2.2.1. Integridade do processamento................................................................. 72
2.2.2. Validação do processamento.................................................................... 73
2.2.3. Tratamento de erros do processamento................................................... 73
2.3. Controles da Saída de Dados......................................................................... 73
2.3.1. Revisão dos dados de saída....................................................................... 73
2.3.2. Distribuição dos dados de saída................................................................. 73
2.3.3. Segurança dos dados de saída................................................................... 74

3. DESENVOLVIMENTO DE SISTEMAS.................................................................. 75
3.1. Fase 1: Planejamento..................................................................................... 75
3.2. Fase 2: Elaboração do plano de desenvolvimento e início do projeto........... 76
3.3. Fase 3: Organização do projeto..................................................................... 77
3.4. Fase 4: Elaboração do projeto do sistema..................................................... 77
3.5. Fase 5: Revisão e aprovação pelos dirigentes.............................................. 78
3.6. Fase 6: Desenvolvimento e Implantação........................................................ 78
3.6.1. Teste do sistema.................................................................................. 79
3.6.2. Implementação..................................................................................... 79
3.6.3. Bibliotecas de controles....................................................................... 80
3.7. Fase 7: Revisão de pós-implementação........................................................ 80

4. BANCO DE DADOS 81
..............................................................................................
4.1. Dicionário de dados ....................................................................................... 81
4.2. Armazenamento de dados ............................................................................ 82
4.3. Acesso ao banco de dados ........................................................................... 82
4.4. Bancos de dados distribuídos ....................................................................... 82
4.5. Administração de banco de dados ................................................................ 83
1
0
 4.6. Administração de dados ................................................................................ 84
4.7. Avaliação de Banco de Dados....................................................................... 84
4.7.1. Controles de Administração de dados................................................. 84
4.7.2. Controles de Administração de banco de dados ................................. 85
4.7.3. Controles de acesso ao banco de dados e dicionário de dados ......... 85
4.7.4. Controles sobre o conteúdo e alterações no dicionário de dados ....... 85
4.7.5. Disponibilidade e recuperação do banco de dados.............................. 86
4.7.6. Integridade do banco de dados ............................................................ 86

5. REDES DE COMPUTADORES ............................................................................ 87

5.1. Avaliação das Redes de Comunicação de Computadores ........................... 88
5.1.1. Gerência de rede.................................................................................. 88
5.1.2. Segurança dos dados .......................................................................... 89
5.1.2.1. Integridade dos dados................................................................ 90
5.1.3. Segurança da rede................................................................................ 90
5.1.3.1. Controle de acesso...................................................................... 90
5.1.3.2. Segurança de comunicação na rede........................................... 91
5.1.4. Segurança física .................................................................................. 91
5.1.5. Plano de contingência........................................................................... 91
5.1.6. Operação da rede................................................................................. 92
5.1.6.1. Falhas e interrupções de serviço................................................ 92
5.1.7. Software de rede................................................................................... 92
5.1.7.1. Controle de alterações................................................................ 93

6. MICROCOMPUTADORES 94
....................................................................................
6.1. Controles do software em uso........................................................................ 95
6.2. Controles de segurança................................................................................. 95
6.3. Controles sobre a operação........................................................................... 96

GLOSSÁRIO............................................................................................................. 97

BIBLIOGRAFIA.......................................................................................................... 102

RELAÇÃO DOS DOCUMENTOS ELABORADOS NA ÁREA DE FISCALIZAÇÃO

E CONTROLE EXTERNO......................................................................................... 104

FOLHA DE SUGESTÕES.......................................................................................... 105

LISTA DE QUADROS

PARTE 1 – TECNOLOGIA DA INFORMAÇÃO E ATIVIDADE DE FISCALIZAÇÃO

Página

1 - Determinação da necessidade ou não de avaliação da confiabilidade dos dados, 19

quando outras evidências comprobatórias estão disponíveis

1
1
2 - Determinação da extensão da avaliação dos controles do sistema 21

3 - Determinação do risco de confiabilidade dos dados, a partir do conhecimento 23

prévio sobre o sistema e o uso planejado para os dados

4 - Determinação dos risco de confiabilidade ajustado dos dados 23

5 - Determinação da extensão do teste de dados 24

PARTE 2 – AUDITORIA DE SISTEMAS DE INFORMAÇÃO

6 - Exemplo de estrutura organizacional para o Departamento de Tecnologia da 44

Informação

1
2
 LISTA DE SIGLAS

CIPFA ......................................... The Chartered Institute of Public Finance and Accountancy

EFS ............................................. Entidade Fiscalizadora Superior

GAO ............................................ United States General Accounting Office

ICAS ........................................... The Institute of Chartered Accountants of Scotland

INTOSAI ..................................... International Organization of Supreme Audit Institutions

NAO ............................................ National Audit Office

TCU ............................................ Tribunal de Contas da União

13
MANUAL DE AUDITORIA DE SISTEMAS

PARTE 1 - TECNOLOGIA DA INFORMAÇÃO E

ATIVIDADE DE FISCALIZAÇÃO

AVALIAÇÃO DA CONFIABILIDADE DE DADOS

PROCESSADOS POR COMPUTADOR
INTRODUÇÃO

Grande parte dos órgãos e entidades sob a jurisdição do TCU já utiliza

maciçamente a tecnologia da informação para automatizar sua operação e registrar,
processar, manter e apresentar informações. Por isso, cada vez mais as equipes de
auditoria terão que usar como evidência dados provenientes de sistemas informatizados.

Não se deve partir do princípio de que dados extraídos de computadores são

confiáveis. Embora ofereçam vantagens para as organizações, os sistemas informatizados
podem também representar grandes riscos. É possível que erros e fraudes não sejam
detectados por causa da enorme quantidade de dados controlados pelos sistemas, da
possível discrepância entre o que está armazenado e o que é efetivamente apresentado em
relatórios de saída, e da mínima necessidade de intervenção humana nos processos.

Este Manual foi elaborado com o intuito de orientar os Analistas do Tribunal em

suas atividades de fiscalização, devendo ser utilizado em auditorias em geral, como parte
das tarefas de planejamento e execução, em complemento às normas e procedimentos de
auditoria adotados pelo TCU.

A primeira parte deste Manual, aplicável a qualquer auditoria, possibilita avaliar se

os dados processados por computador, que servirão de evidência para os achados de
auditoria, são confiáveis, ou seja, completos e exatos. A segunda parte é voltada
especificamente para as auditorias de sistemas, onde os sistemas computacionais serão
analisados detalhadamente.

Seguindo as instruções da primeira parte deste Manual, os usuários estarão

capacitados a constatar, com segurança, se as informações que irão fundamentar o relatório
são íntegras e se possuem um grau de precisão adequado ao alcance dos objetivos de
auditoria.

Para o bom aproveitamento das informações apresentadas, é recomendável que

os usuários já possuam conhecimentos elementares de informática, abrangendo hardware
dos computadores, softwares aplicativos, redes de comunicação e outras noções
apresentadas em cursos introdutórios ao Processamento Eletrônico de Dados.

15
1. REQUISITOS PARA A UTILIZAÇÃO DE EVIDÊNCIA PROVENIENTE DE DADOS
PROCESSADOS POR COMPUTADORES

Ao utilizar dados fornecidos por computador para fundamentar achados de

auditoria, a equipe precisa levar em consideração as seguintes questões :

 Qual a importância desses dados para o alcance dos objetivos da auditoria?

 Os dados podem ser considerados completos e exatos? O que se sabe sobre
o sistema que os processou?

Quando os dados processados por computador são utilizados pela equipe de

auditoria ou incluídos no relatório apenas com o propósito de fornecer um histórico ou
relatar fatos não significativos para os resultados do trabalho, a citação da fonte dos dados
no relatório normalmente será suficiente para estabelecer a confiabilidade das informações
apresentadas. Se esses dados servirem como o principal instrumento para se atingir os
objetivos de auditoria, a equipe deve atestar sua confiabilidade, mediante a prática de
procedimentos de avaliação tanto dos dados quanto do sistema que os processou. Os
dados somente poderão ser considerados confiáveis se forem completos (sem omissões ou
inclusões indevidas capazes de distorcer as análises) e exatos (sem incorreções
significativas nos valores atribuídos). Eles não precisam estar 100% corretos, mas têm que
representar "adequadamente" o universo auditado. Na prática, pode ser que a equipe de
auditoria tenha que estimar, com a ajuda de métodos estatísticos, o valor provável do erro
máximo dos dados, ou "limite superior do erro", e compará-lo com o nível de materialidade,
a ser estabelecido levando-se em conta o uso previsto para os dados.

A determinação da confiabilidade dos dados é necessária independentemente de

serem eles fornecidos pela organização auditada ou extraídos dos sistemas pela própria
equipe de auditoria.

A análise da confiabilidade dos dados processados por computador deve ser

iniciada ainda na fase de planejamento da auditoria, sempre que os estudos preparatórios
permitam identificar e investigar as fontes dos dados que irão servir para se alcançar os
objetivos de auditoria.

Se os dados a serem utilizados não forem suficientemente confiáveis para

atender aos objetivos da auditoria, eles não servem de evidência primária, e a equipe terá
que planejar um procedimento alternativo. As seguintes opções devem ser consideradas e
discutidas com os superiores:

 obter os dados de outras fontes, cuja confiabilidade possa ser confirmada;

 coletar dados primários para atender aos objetivos, em vez de utilizar fontes
secundárias (esse procedimento somente pode ser adotado se for possível
completar o trabalho no tempo previsto para a auditoria);
 redefinir os objetivos da auditoria, para eliminar a necessidade de utilizar dados
não confiáveis;
 utilizar os dados, explicando sua limitação e abstendo-se de extrair conclusões
ou recomendações;
 interromper a tarefa se nenhuma outra alternativa for possível.

16
2. MÉTODOS DE AVALIAÇÃO DE DADOS PROCESSADOS POR COMPUTADOR

A eficácia da utilização dos procedimentos aqui recomendados dependerá da

capacidade da equipe de auditoria em julgar a qualidade dos controles do sistema e a
extensão e forma do teste dos dados. Erros nesse julgamento podem trazer conseqüências
indesejáveis: um aprofundamento excessivo da investigação desperdiça recursos valiosos,
enquanto um esforço insuficiente põe em risco a confiabilidade do trabalho. Em algumas
circunstâncias, a equipe poderá concluir ser necessária a presença de um especialista na
área de auditoria de sistemas informatizados para auxiliá-la no trabalho. Para que esse
auxílio possa ser providenciado, o coordenador da equipe deverá informar o fato ao
responsável pela supervisão do trabalho.

Existem basicamente dois métodos para a avaliação da confiabilidade de dados

extraídos de computadores:

Avaliação do sistema: testa e avalia com profundidade todos os controles num

sistema informatizado, abrangendo suas aplicações e produtos. Os
procedimentos utilizados são: (1) exame dos controles gerais e de aplicativos do
sistema; (2) teste da observância dos controles; e (3) teste dos dados produzidos
pelo sistema. Apesar de oferecer uma melhor compreensão da finalidade e da
forma de operação do sistema, este tipo de avaliação tende a consumir muito
tempo e exige a participação de um especialista na área de Auditoria de Sistemas
Informatizados.

Avaliação limitada: é direcionada para dados específicos. Por essa razão, ela
normalmente requer uma avaliação menos profunda dos controles gerais e de
aplicativos, podendo ser realizada por equipes compostas, somente, por técnicos
generalistas. Os controles pertinentes são examinados na extensão necessária
para julgar o grau de abrangência dos testes a serem feitos nos dados visando a
determinar sua confiabilidade.

Há casos em que opção pela avaliação do sistema será mais vantajosa. Por
exemplo: quando uma unidade técnica utiliza repetidamente dados do mesmo sistema
informatizado em suas atividades de fiscalização. Nessas circunstâncias, uma avaliação
extensiva, periodicamente atualizada, pode revelar-se menos onerosa, a longo prazo, que
sucessivas avaliações limitadas dos dados. Para execução de uma avaliação extensiva
deve-se utilizar os capítulos 1 e 2 da Parte 2 deste Manual. Na maioria das auditorias,
entretanto, o segundo método de avaliação é adequado e suficiente, podendo ser aplicado
através das técnicas e procedimentos constantes dos itens 3 e 4 seguintes.

17
3. TÉCNICAS
DOS DADOS
E PROCEDIMENTOS DE AVALIAÇÃO LIMITADA DA CONFIABILIDADE

Para se determinar a confiabilidade de dados processados por computador, pelo

método de avaliação limitada, são utilizados os seguintes passos:

1) Determinação do uso dos dados - decidir quais os dados processados por

computador irão ser utilizados para se alcançar dos objetivos de auditoria,
assim como de que maneira esses dados serão utilizados, identificando
aqueles que: (a) provavelmente irão servir como única evidência para um
achado; (b) poderão ser confirmados por outras fontes independentes; (c)
servirão apenas como referência para os trabalhos, não influindo nos
resultados da auditoria;

2) Definição dos dados que deverão ter sua confiabilidade avaliada;

3) Levantamento do conhecimento prévio sobre o sistema e/ou os dados;

4) Avaliação dos controles do sistema de processamento dos dados -

restrita aos controles relevantes do sistema, que podem reduzir o risco de erro
para um nível aceitável;

5) Determinação do risco de confiabilidade dos dados e da extensão do

teste de dados;

6) Teste de dados - execução de procedimentos para avaliar a integridade e

autenticidade dos dados e a exatidão do seu processamento por computador;

7) Divulgação da fonte dos dados e da confiabilidade atribuída aos mesmos.

Sempre que possível, as atividades relacionadas aos passos 1 a 3 devem ser

executadas durante a etapa de planejamento da auditoria. Entretanto, em muitos casos não
será possível obter ainda nessa fase as informações necessárias. Nessas situações ou
quando durante os trabalhos surgirem novas evidências ou achados que exijam o uso de
outros dados processados por computador, todas as etapas poderão ser cumpridas no
período de execução da auditoria.

A seguir, são apresentados as técnicas e procedimentos associados a cada

etapa da avaliação da confiabilidade dos dados.

3.1. Determinação do uso dos dados

Quando uma auditoria requer o uso de dados processados por computador, o

primeiro passo é decidir como eles serão utilizados para se alcançar os objetivos de
auditoria. Normalmente, os dados são utilizados como:

 única evidência para fundamentar um achado;

 evidência auxiliar, ou de ratificação; ou
 informação geral (histórico, descrições etc.).

18
 Inicialmente, deve-se identificar os dados e sistemas a serem utilizados. Em
seguida, cada grupo de dados deve ser classificado de acordo com sua utilidade (única
evidência, comprovação auxiliar ou dado de informação geral).

3.2. Definição dos dados que deverão ter sua confiabilidade avaliada

A partir da definição do uso a ser dado às informações provenientes de sistemas

informatizados, pode-se determinar quais os grupos de dados que precisarão ter sua
confiabilidade avaliada, antes de poderem ser utilizados como evidência no relatório de
auditoria. Com base na classificação definida no passo anterior, tem-se uma das seguintes
situações:

Dados classificados como única evidência - quando os dados processados

por computador são o único suporte para um objetivo de auditoria, o grau de
confiabilidade exigido deles é alto, devendo a equipe de auditoria proceder a um
rigoroso teste de avaliação dos dados e do sistema.

Dados classificados como evidência auxiliar - quando os dados processados

por computador podem ser ratificados por outras comprovações de auditoria, o
grau de confiabilidade exigido vai depender do quanto as outras evidências
seriam suficientes para, vistas isoladamente, respaldar as conclusões.

Dados classificados como de informação geral - menor risco de se usar dados

informatizados ocorre quando esses têm uma função apenas informativa, não
contribuindo para os resultados da auditoria. Nesse caso, a citação da fonte dos
dados e a garantia de que estes são os melhores disponíveis satisfarão os
padrões de confiabilidade esperados do relatório, a menos que haja razão para
se acreditar que uma falta de rigor nos dados pode distorcer os resultados do
trabalho.

O Quadro a seguir resume as implicações dos três usos possíveis para os dados.

Quadro 1 - Determinação da necessidade ou não de avaliação da confiabilidade dos dados quando outras
evidências comprobatórias estão disponíveis.

CARACTERÍSTICAS DAS OUTRAS EVIDÊNCIAS EXIGÊNCIA DE AVALIAÇÃO

TIPO DE USO DOS DADOS PROCESSADOS
POR COMPUTADOR
Única evidência - SIM
Fonte primária de informação (ex.:
comprovação física da existência de um NÃO
bem, documento bancário que confirma
um valor declarado etc.)
Evidência auxiliar
Fontes auxiliares que por si sós não
SIM
podem ser consideradas suficientes (ex.:
entrevista com funcionários da unidade)
Informação geral Fontes primárias ou auxiliares NÃO
Inexistentes NÃO*
(*) A menos que haja razões para se acreditar que uma falta de rigor nos dados pode de alguma forma distorcer
os resultados do trabalho
3.3. Levantamento do conhecimento prévio sobre o sistema e/ou os dados

19
 Nos casos em que se inferiu a necessidade de avaliação da confiabilidade dos
dados, a próxima etapa consiste no levantamento de todas as informações disponíveis
sobre o sistema e os dados.

Informações favoráveis sobre a confiabilidade do sistema ou dos dados podem

reduzir o risco de confiabilidade, e diminuir o trabalho de avaliação dos controles do sistema
e de teste de dados. Informações desfavoráveis levarão ao aumento do risco, exigindo
maior cuidado na avaliação dos controles e na realização de testes de dados, os quais
deverão ser suficientes para garantir que as informações que irão servir de evidência sejam
completas e exatas.

Os seguintes exemplos ilustram como a equipe pode saber mais sobre os dados
ou o sistema que os processou:

 Os mesmos dados já foram utilizados em auditorias anteriores, após ter sido

estabelecida sua confiabilidade. O risco de se utilizar os mesmos dados
novamente em outro relatório seria baixo, mas seria necessário averiguar se os
dados não foram modificados após a última auditoria.
 Os controles do sistema que processou os dados foram avaliados em uma
auditoria recente e considerados adequados. Após certificar-se de que
nenhuma mudança significativa ocorreu no sistema desde aquela avaliação, a
equipe de auditoria pode reduzir a extensão do teste de dados que irá
determinar sua confiabilidade.
 Uma auditoria de sistemas informatizados, executada recentemente, abrangeu
o sistema responsável pelo processamento dos dados sob exame, ainda que
em outra aplicação. Os resultados dessa avaliação do sistema, após
confirmada a ausência de alterações significativas em sua operação, podem
ser utilizados para definir a amplitude dos testes a serem realizados nos
dados.

3.4. Avaliação dos controles do sistema de processamento dos dados

Durante a fase de execução da auditoria, e antes de se proceder ao teste de

dados (procedimento que, em última instância, irá determinar a sua confiabilidade),
normalmente é indicada a avaliação dos controles presentes no sistema de processamento
desses dados.

Segundo princípios geralmente aceitos de auditoria, quanto menor a

confiabilidade dos controles gerais ou de aplicativo (ou se esses não forem avaliados),
maior a extensão do teste necessário para determinar a confiabilidade dos dados.

A abrangência da avaliação dos controles depende do conhecimento prévio sobre

os dados e o sistema. O quadro 3 mostra como pode ser definida a extensão da avaliação
dos controles a partir das informações obtidas:

20
Quadro 2 - Determinação da extensão da avaliação dos controles do sistema

AMPLITUDE DA AVALIAÇÃO
CONHECIMENTO PRÉVIO SOBRE USO PLANEJADO PARA OS DADOS DOS CONTROLES DO
O SISTEMA OU OS DADOS
SISTEMA
As informações são Única evidência para possíveis Extensiva
insuficientes ou avaliações achados
anteriores detectaram erros Evidência auxiliar Moderada
significativos nos controles Desnecessária*
Informações gerais (histórico,
do sistema ou nos próprios
descrição etc.)
dados.
A confiabilidade do sistema Única evidência para possíveis Moderada
ou dos dados já foi avaliada achados
e considerada adequada em Evidência auxiliar Reduzida
trabalhos anteriores.
Informações gerais (histórico, Desnecessária
descrição etc.)
(*) A menos que haja razões para se acreditar que uma falta de rigor nos dados pode de alguma forma
distorcer os resultados do trabalho. Nesse caso, a equipe deve decidir entre avaliar a existência e eficácia dos
elementos-chave de controle, desistir do uso das informações ou confirmar sua validade através de outras
fontes.

No item 4 deste módulo, são apresentados os procedimentos para a avaliação

dos controles dos sistemas, nos três níveis indicados (extensivo, moderado e reduzido).

A seguir, apresentam-se os indícios que podem caracterizar a inadequação dos

controles de sistema, e um método para a classificação desses controles, de acordo com o
grau de eficácia a eles atribuído.

3.4.1. Indícios de ineficácia dos controles de sistema

Ainda que bem planejados e projetados, se aplicados de forma inconsistente ou

incorreta, os controles de sistema serão ineficazes. Há muitas razões para que os controles
sejam desconsiderados ou ignorados pelo pessoal envolvido, tais como falta de tempo,
fadiga, tédio, falta de atenção, controles que oneram a operação do sistema e até mesmo
conluio para ganho pessoal. Por esse motivo, a equipe deve selecionar os procedimentos
de controle mais significativos e confirmar sua eficácia.

A documentação de um sistema bem controlado deve ser completa e atualizada.

A ausência dessa documentação pode indicar que não existem controles, que eles não são
compreendidos ou são inadequadamente aplicados. Outros sinais que sugerem
vulnerabilidade de dados a erros podem ser:

 sistemas antigos, que exigem muita manutenção;

 grande volume de dados;
 atividades de atualização muito freqüentes;
 numerosos tipos de transação e de fontes de dados;

21
  grande número de elementos de dados codificados (por exemplo, itens do
estoque representados por meio de códigos numéricos, em vez do nome do
bem, podem dificultar a identificação até mesmo de erros grosseiros);
 alta rotatividade de pessoal (digitadores, operadores, programadores,
analistas) e treinamento inadequado ou em escala insuficiente;
 estruturas de dados complexas ou desorganizadas;
 falta de padrões para o processamento de dados, especialmente quanto à
segurança, acesso e controle de mudança de programas.

Entrevistas com funcionários com grande conhecimento da organização podem

auxiliar a equipe no entendimento dos controles do sistema. A evidência testemunhal,
entretanto, sempre que possível, deve ser corroborada através de observação direta e
outros testes, como prevê o Manual de Auditoria do TCU.

3.4.2. Parecer sobre a eficácia dos controles do sistema

Após avaliar os controles do sistema, a equipe deverá dar um parecer sobre a

sua eficácia, isso é, sua capacidade de prevenir erros e detectar e corrigir aqueles que
venham a ocorrer.

De acordo com os resultados da análise efetuada, a equipe de auditoria irá

classificá-los em:

Controles sólidos - quando assumir-se que o sistema como um todo está

capacitado a prevenir, detectar e corrigir qualquer erro significativo nos dados;

Controles adequados - quando forem detectadas deficiências nos controles,

mas de modo geral esses demonstrarem ser suficientes para prevenir os erros
mais significativos, e acusar os que venham a ocorrer; ou

Controles fracos/indeterminados - quando identificar-se a ausência ou

ineficácia dos controles de sistema, e, conseqüentemente, oportunidades de
introdução de dados incorretos no sistema.

A opinião da equipe quanto ao grau de eficácia dos controles dependerá de

evidência que seja ao mesmo tempo relevante e confiável. Assim como em outras
atividades de auditoria (conforme prevê o Manual de Auditoria do TCU), pode ser
necessário definir índices de materialidade e outros critérios a serem observados como base
de comparação, julgamento e apreciação de desempenho.

3.5. Determinação do risco de confiabilidade dos dados

O risco de confiabilidade dos dados é definido como sendo o "risco de que os

dados utilizados não sejam suficientemente confiáveis para o fim a que se destinam", ou
seja, o risco de que esses não sejam exatos e completos o suficiente para servir de
fundamento para achados de auditoria.

A partir das informações reunidas e do uso planejado para os dados, pode-se

identificar o risco de confiabilidade envolvido, a ser definido como alto, moderado ou baixo,
como mostra o quadro abaixo.
22
Quadro 3 - Determinação do risco de confiabilidade dos dados, a partir do conhecimento prévio sobre o sistema
e o uso planejado para os dados.

CONHECIMENTO PRÉVIO SOBRE USO PLANEJADO PARA OS

RISCO DE CONFIABILIDADE
O SISTEMA OU OS DADOS DADOS
As informações são Única evidência para Alto
insuficientes ou avaliações possíveis achados
anteriores detectaram erros
significativos nos controles Evidência auxiliar Moderado
do sistema ou nos próprios Informações gerais (histórico, Baixo
dados. descrição etc.)

A confiabilidade do sistema Única evidência para Moderado

ou dos dados já foi avaliada possíveis achados
e considerada adequada em Evidência auxiliar Baixo
trabalhos anteriores. Informações gerais (histórico, Muito baixo
descrição etc.)

O risco de confiabilidade dos dados pode ser ajustado pelos resultados da

avaliação dos controles do sistema, como mostra o quadro a seguir.

Quadro 4 - Determinação do risco de confiabilidade ajustado dos dados

RISCO DE CONFIABILIDADE
 AVALIAÇÃO DOS CONTROLES DO =
RISCO DE CONFIABILIDADE
INICIALMENTE CALCULADO SISTEMA AJUSTADO
Alto Fracos/Indeterminados Alto
Adequados Alto a moderado
Sólidos Moderado a baixo
Moderado Fracos/Indeterminados Moderado
Adequados Moderado a baixo
Sólidos Baixo
Baixo Fracos/Indeterminados Baixo
Adequados Baixo a muito baixo
Sólidos Muito baixo
Muito baixo normalmente não necessária e de Muito baixo
alto custo-benefício

Com a determinação do risco de confiabilidade ajustado, define-se a extensão do

teste de dados, como mostra o quadro 5.

23
Quadro 5 - Determinação da extensão do teste de dados.
RISCO DE CONFIABILIDADE ABRANGÊNCIA DO TESTE DE DADOS
Alto Extensivo
Moderado Moderado
Baixo Reduzido

3.6. Teste de dados

Os princípios de auditoria exigem que qualquer evidência (independentemente de

sua fonte ou formato) seja confiável, relevante e suficiente. O teste dos dados tem o objetivo
de estabelecer a consistência deles em relação ao uso planejado.

Algum teste de dados sempre será necessário quando se pretende avaliar a

confiabilidade de informações processadas por computador. Mesmo quando os controles do
sistema são bem projetados e, de modo geral, eficazes, a exatidão dos dados não é
garantida. Ainda que a equipe possa fiar-se em bons controles para reduzir a amplitude do
teste dos dados, como demonstra o quadro 5, a avaliação dos controles do sistema não
pode substituí-lo.

Embora seja improvável que qualquer sistema de computador contenha dados

completamente livres de erro, o conceito de confiabilidade não exige dados perfeitos. Ele
pressupõe, no entanto, a execução de procedimentos para avaliar a integridade e
autenticidade dos dados e a exatidão do seu processamento por computador, abrangendo:

Testes da integridade dos dados: determinam se o universo contém todos os

elementos de dados e registros relevantes para o objetivo de auditoria, no
período abrangido. A omissão de dados é particularmente danosa se ela
representar um segmento específico da população total (exemplo, todos os
pagamentos efetuados a um mesmo fornecedor).

Testes de autenticidade dos dados: verificam se os dados computadorizados

refletem com exatidão sua fonte (os registros de entrada de dados devem
reproduzir fielmente os documentos-fonte).

Testes de exatidão do processamento: informam se todos os registros

relevantes foram processados de forma completa, e se todos os processamentos
atenderam aos objetivos pré-estabelecidos.

Existem duas maneiras de se testar dados processados por computador. Elas

são diferenciadas pela participação ou não do sistema computadorizado no processo. O
método apropriado, ou a combinação de métodos, vai depender da natureza do sistema
envolvido.

3.6.1. Auditoria sem o auxílio do computador

A auditoria sem o auxílio do computador parte do princípio de que as técnicas e

procedimentos que o computador utiliza para processar dados não precisam ser
considerados, desde que exista uma trilha de auditoria visível e/ou o resultado do processo
possa ser manualmente verificado. Existem três formas de se realizar esse tipo de auditoria:
confrontação dos dados de entrada e saída do computador com fontes independentes,

24
duplicação manual dos processos executados pelo computador e verificações ditadas pelo
senso comum, as quais serão descritas a seguir.

3.6.2. Confrontação dos dados de entrada e saída do computador com

fontes independentes

Este procedimento confronta os dados mantidos pelo computador com os dados

provenientes de outras fontes (tais como relatórios de inspeção, arquivos, registros
documentais), ou compara dados com contagens físicas ou inspeções que confirmem
quantidades, tipos e condições de bens tangíveis. Relatórios de programas do governo e
outros documentos produzidos por terceiros (tais como universidades, auditorias
independentes e organizações privadas) também podem fornecer uma base de dados útil
para comparação.

Outras fontes independentes das quais pode-se obter confirmação incluem:

 bancos (extratos bancários, etc.);

 almoxarifado (bens armazenados, volume de saída, etc.);
 instituições de treinamento (número de estudantes ou valor dos contratos).

3.6.3. Duplicação manual dos processos executados pelo computador

Outro meio de se evitar o uso do computador ao confirmar a confiabilidade dos

dados é selecionar transações, duplicar manualmente os processos do computador e
comparar os resultados com a saída de dados. Esse procedimento poderia ser usado, por
exemplo, em uma auditoria na área de licitações e contratos, em que os dados relativos aos
contratos auditados fossem processados por um sistema informatizado. Nesse caso, a
equipe poderia utilizar uma fórmula matemática para o cálculo do reajuste dos preços
contratuais, a ser aplicada a uma amostra de contratos, para a posterior confrontação com
os valores calculados pelo sistema auditado.

3.6.4. Verificações ditadas pelo senso comum

É possível, também, revelar problemas potenciais de confiabilidade, por meio de

verificações ditadas pelo senso comum. As questões a seguir são exemplos de testes que
podem ser executados, especialmente nos casos em que for concluído que um teste
reduzido de dados já é suficiente para atender aos objetivos do trabalho (quando testes
extensivos ou moderados forem necessários, essas verificações devem ser completadas
com outros testes mais abrangentes):
 os valores são pequenos demais (o custo mensal de manutenção dos veículos
da entidade é igual a R$ 0,01) ou muito altos (uma bolsa de estudante no valor
de R$ 200.000,00).
 os campos de dados não estão todos preenchidos (as datas de pagamento
mensal de um contrato estão em branco).
 os resultados são inválidos (o valor do inventário é um número negativo).

25
 3.6.5. Observações sobre o uso da auditoria sem o auxílio do computador

Apesar de os testes mencionados indicarem a precisão dos dados mantidos pelo

computador, é muito difícil identificar todas as situações que ameacem a integridade e a
autenticidade dos dados, assim como a exatidão do processamento. Quando a
autenticidade dos dados do computador estiver sob suspeita (ou seja, quando existir a
possibilidade da presença de dados fictícios), deve ser considerada a hipótese de
complementação dos testes através do rastreamento de uma amostra de dados da saída do
computador até os seus documentos-fonte. Se a dúvida for quanto à integridade dos dados
(isto é, quando houver suspeita de que os dados não estão completos), uma amostra válida
de documentos-fonte pode ser acompanhada até se chegar aos dados de saída do sistema,
para confirmar se todos os documentos de origem foram devidamente inseridos.

A utilidade de se auditar sem o auxílio do computador diminui à medida que

aumenta o número e a complexidade das decisões por ele tomadas, podendo tornar-se
inviável quando o processamento dos dados abranger muitos elementos e operações que
dificultem a análise manual dessas informações.

3.6.6. Auditoria com o auxílio do computador

Auditar com o auxílio do computador, no contexto deste manual, significa utilizar

testes programados em computador para auxiliar a medição da confiabilidade dos dados.

Após a determinação da integridade e exatidão dos documentos-fonte, utilizam-

se testes programados por computador (que podem ser desenvolvidos pela própria equipe
de auditoria) para examinar a legitimidade dos dados e identificar defeitos que poderiam
torná-los não confiáveis.

Uma vantagem de se auditar com o auxílio do computador é que esse método

pode ser usado independentemente da complexidade do sistema ou do número de decisões
que o computador tem que tomar durante o processo. Tal procedimento proporciona, além
de rapidez e exatidão, uma amplitude muito maior de teste do que seria possível com outros
métodos.

Para se desenvolver um teste de dados programado em computador, é

necessário identificar quais os elementos de dados que afetam os objetivos de auditoria.
Todos os dados significativos para os resultados da auditoria devem ser testados.

Quando um elemento de dado significativo para a auditoria é derivado (isto é,

calculado pelo computador baseado em outros elementos de dados), a equipe deve
também testar os elementos de dados de origem. Por exemplo, o elemento “salário líquido”
pode ser empregado como evidência para atingir um objetivo de auditoria. Se o dicionário
de dados do sistema indicar que um programa de computador usa três outros elementos de
dados (salário por hora de trabalho, horas trabalhadas e deduções) para calcular esse valor,
erros em quaisquer desses elementos acarretariam erros no valor do pagamento. Dessa
forma, a equipe deve determinar a exatidão de cada um desses elementos.

Alguns sistemas possuem ambiente de processamento de dados de teste, com

funções idênticas às do ambiente de operação normal. Esse ambiente é comumente
utilizado para testes de sistemas e aplicativos antes de sua aprovação pelos usuários, e
pode ser aproveitado pela equipe de auditoria para o processamento e análise de dados de
teste.

26
 3.7. Divulgação da fonte dos dados e da confiabilidade atribuída aos
mesmos

Concluído o processo de avaliação da confiabilidade dos dados, é necessário

documentar os resultados obtidos, mediante o preenchimento de papéis de trabalho e a
inclusão de um parecer no relatório de auditoria.

3.7.1. Papéis de trabalho

Os papéis de trabalho devem ser documentados de forma a deixarem claro:

 os objetivos de auditoria que serão fundamentados por dados processados por

computador;
 o grau de importância desses dados para os objetivos de auditoria, e as fontes
adicionais que podem confirmá-los;
 as informações coletadas sobre os dados, o sistema que os processa e seus
controles.

3.7.2. Informações que devem constar do relatório

Quando os dados processados por computador são usados apenas para

elaboração de histórico, descrição, ou informação geral sobre o órgão, e não têm influência
sobre os resultados de auditoria, geralmente será suficiente a citação da fonte dos dados no
relatório. Para os dados processados por computador que sejam cruciais para os objetivos de
auditoria, o relatório deve assegurar aos leitores que a informação em que se baseia é
confiável. Especificamente, devem ser informados:

 a abrangência da avaliação dos controles, quando a confiança atribuída aos

controles do sistema é utilizada para reduzir o teste de dados;
 os tipos de teste de dados executados, seu propósito, e as taxas de erro
encontradas nas três áreas de operação (entrada, processamento e saída de
dados);
 qualquer fator conhecido que limite a confiabilidade dos dados, e o tipo de
influência que essa limitação teria sobre os resultados e conclusões
apresentados

Se uma amostragem foi usada para determinar a confiabilidade dos dados, o

relatório deverá incluir o objetivo de sua utilização, os tamanhos do universo e da amostra, a
base para o dimensionamento da amostra, o tipo de amostra (randômica, sistemática etc.) e
os erros porventura detectados.

No caso de a confiabilidade dos dados não ter sido determinada no nível

desejado, o relatório deverá incluir uma declaração clara dessa situação. A equipe deverá
considerar a conveniência de se apresentar conclusão ou proposta de determinação
baseada nesses dados.

3.7.3. Modelos a serem utilizados nos relatórios

27
 A seguir, apresentam-se exemplos que ilustram as formas como podem ser
apresentados os resultados da avaliação da confiabilidade dos dados em relatórios:

Dados confiáveis são utilizados:

“Para alcançar o objetivo de auditoria, nos baseamos em dados processados pelo
sistema (citar a base de dados utilizada). Avaliamos a confiabilidade desses
dados através dos controles gerais e de aplicação relevantes, e os consideramos
adequados. Também conduzimos testes suficientes nos dados. Baseados nesses
testes e avaliações, concluímos que os dados são suficientemente confiáveis
para serem utilizados como evidência para fundamentar as conclusões e
proposições apresentadas."

Dados não confiáveis não são utilizados:

“Para alcançar o objetivo de auditoria, nos baseamos em dados processados pelo
sistema (citar a base de dados utilizada). A avaliação dos controles dos sistema e
o resultado dos testes de dados demonstram uma taxa de erro que coloca em
dúvida a validade dos dados. Uma vez que o objetivo de auditoria depende de
informações baseadas nesses dados, e fatos e provas suficientes para servir de
evidência independente não estão disponíveis, não nos foi possível prover
projeções, conclusões ou propostas de determinação específicas.”

A confiabilidade não foi estabelecida:

“Para alcançar o objetivo de auditoria, nos baseamos em dados processados pelo
sistema (citar a base de dados utilizada). Não estabelecemos a confiabilidade
desses dados porque (citar as razões). Desta forma, estamos impossibilitados de
prover projeções, conclusões ou determinações sobre esses dados. Com
exceção do acima informado, o trabalho foi conduzido de acordo com os padrões
previstos nas normas e procedimentos de auditoria adotados por este Tribunal.

28
4. ROTEIRO PARA AVALIAÇÃO DOS CONTROLES DE SISTEMA

Neste item são apresentados os conceitos básicos sobre controles de sistemas

informatizados, os elementos que determinam a eficácia desses controles, e os roteiros para
as avaliações (1) extensiva, (2) moderada e (3) reduzida. As verificações sugeridas não são
obrigatórias, devendo a equipe de auditoria decidir sobre os itens adequados a cada
situação concreta. O tempo e esforço gastos com a avaliação dos controles do sistema
devem ser proporcionais à sua possível influência na redução do teste de dados: o “custo”
de avaliação dos controles não pode ultrapassar o “benefício” da diminuição de trabalho na
fase de teste de dados.

Se for concluído que os controles do sistema são insuficientes para limitar o teste
de dados ou que continuar a avaliação dos controles será mais custoso que efetuar um
teste extensivo de dados, a fase de avaliação dos controles do sistema deve ser
interrompida. Nesses casos, a equipe deve passar para a etapa de teste extensivo de
dados, como se os controles do sistema fossem fracos ou inexistentes.

Os controles dos sistemas informatizados são classificados em dois grupos

principais: controles gerais, que se aplicam a todos os processamentos executados em um
ambiente informatizado, visando garantir que o ambiente computacional como um todo seja
seguro e confiável; e controles de aplicação ou de aplicativos, incorporados diretamente em
aplicações individuais, com o objetivo de garantir um processamento confiável e exato.

É apresentado, a seguir, um roteiro com os aspectos mais importantes desses

controles, quando o propósito da avaliação é permitir uma redução no volume de testes de
dados.

4.1. . Controles Gerais

São controles que se aplicam a todos os processamentos executados em um

ambiente informatizado, visando a garantir que o ambiente computacional como um todo
seja eficiente, eficaz, seguro e confiável. Estão relacionados à organização, projeto,
desenvolvimento, modificação e segurança dos sistemas

4.1.1. Controles Organizacionais:

Objetivo - garantir a organização das responsabilidades do pessoal envolvido

nas funções de processamento de dados e os padrões estabelecidos para o seu
funcionamento eficiente.

Procedimentos de controle - verificar a existência dos seguintes elementos de

controle:

 Participação ativa da alta administração e dos gestores do sistema nas

decisões que afetam o processamento de dados.
 Avaliações rotineiras das funções de processamento de dados pela auditoria
interna ou externa.
29
  Evidência de ações efetivas de acompanhamento em relação às
recomendações de auditoria.
 Adequada segregação de funções dentro da operação do processamento de
dados. As seguintes funções devem ser preferivelmente executadas por
diferentes indivíduos ou grupos:
 análise de sistemas;
 programação de aplicações;
 teste de aceitação;
 controle de alteração de programa;
 controle de dados;
 manutenção de sistemas de software; e
 manutenção de arquivos informatizados, e operação do equipamento de
informática.

4.1.2. Controles de projeto, desenvolvimento e modificação de sistemas

Objetivo - assegurar que os sistemas atendam às necessidades dos usuários,

sejam desenvolvidos com economicidade, sejam totalmente documentados e testados e
incluam os controles internos apropriados.

Procedimentos de controle - verificar a existência dos seguintes elementos de

controle:

 Procedimentos formais para requisitar, aprovar, testar e implementar

mudanças no sistema.
 Método formal de abordagem para o desenvolvimento de sistemas.
 Envolvimento dos usuários no desenvolvimento dos requisitos dos sistemas
 Documentação atualizada sobre o sistema, incluindo:
 documentos de requisitos funcionais;
 requisitos de coleta de dados;
 características de projeto dos sistemas e subsistemas;
 manual do usuário;
 manual de operação do sistema;
 estratégia para teste do sistema automatizado, incluindo procedimentos de
teste e critérios de avaliação;
 relatórios de análise de teste, documentando os resultados e conclusões
dos testes efetuados.

30
 4.1.3. Controles de segurança

Objetivo - garantir que os computadores e os dados processados estão

adequadamente protegidos contra roubo, perda, acesso não autorizado e desastres
naturais.

Procedimentos de controle - verificar a existência dos seguintes elementos de

controle:

 Análise de risco periódica;

 Responsabilidades pela segurança dos computadores formalmente
estabelecidas;
 Acesso ao centro de processamento de dados controlado por algum
mecanismo físico (porta trancada, crachás de segurança, etc.);
 Permanência de pelo menos duas pessoas na sala de computação durante
todo o expediente;
 Responsabilidade pelo armazenamento de dados magnéticos claramente
documentada;
 Plano de recuperação de desastres, periodicamente testado;
 Senhas individuais de acesso aos sistemas, alteradas periodicamente e não
sujeitas a divulgação pelos usuários; e
 Software de controle do acesso aos computadores, encarregado de identificar
os usuários e verificar a permissão de uso das pessoas que tentam ganhar
acesso.

4.2. Controles de aplicativos

Objetivo - garantir que o processamento seja confiável e exato, a partir de

controles incorporados diretamente em programas aplicativos, nas três áreas de operação
(entrada, processamento e saída de dados).

Procedimentos de controle - verificar a existência dos seguintes elementos de

controle:

4.2.1. Controle da entrada de dados

São projetados para garantir que os dados sejam convertidos para um formato
padrão e inseridos na aplicação de forma precisa, completa e tempestiva. Controles a serem
verificados:

 Procedimentos documentados para a inserção de dados na aplicação;

 Procedimentos de autorização física ou eletrônica para os registros de entrada;
 Medidas de segurança para limitar o acesso aos terminais de entrada e validar
a inscrição de usuários;
 Validação de todos os campos de dados, antes de sua entrada no sistema;

31
  Rejeição e armazenagem automática de dados que não atendam aos
requisitos de entrada em um arquivo de dados de processamento interrompido;
 Procedimentos documentados para o tratamento de erros (identificação,
correção e reprocessamento de dados rejeitados pela aplicação);
 Análise periódica do arquivo de processamento interrompido para examinar a
taxa de erro de entrada de dados e a situação dos registros não corrigidos;
 Medidas corretivas para redução de taxas de erro excessivas;
 Controle da integridade dos dados de entrada, por meio da confrontação entre
total de registros inseridos (registros rejeitados + registros aceitos) e o total de
documentos de origem.

4.2.2. Controles do processamento de dados

São utilizados para garantir que os dados sejam manipulados pelo computador
de uma forma precisa, completa e tempestiva. Devem ser verificados:

 Procedimentos documentados sobre os métodos de processamento utilizados

(ex.: fórmulas usadas para o cálculo de juros, tabelas consultadas para o
cálculo do vencimento básico etc.);
 Registro histórico que armazene eventos registrados pelo computador e seus
operadores, durante o processamento de aplicações;
 Proteção contra o acesso e alteração de programas aplicativos através de
terminais de operação;
 Proteção dos sistemas on-line contra a atualização simultânea de arquivos por
diferentes usuários;
 Testes de integridade de arquivos para garantir que os arquivos do aplicativo
foram completamente processados.

4.2.3. Controles da saída de dados

Presentes para garantir a integridade e a correta e tempestiva distribuição dos

dados de saída. Devem ser verificados os seguintes pontos:

 Procedimentos documentados para confirmação da validade dos produtos de

saída, e sua distribuição adequada;
 Entrevista periódica dos usuários, para determinar se os dados produzidos
continuam sendo necessários ou úteis;
 Produtos de saída etiquetados para identificar o nome do produto, nome do
destinatário e data e hora de produção;
 Procedimentos documentados sobre os métodos para relatar, corrigir e
reprocessar produtos de saída com erros;
 Conferência dos montantes de registros de entrada e de saída com totais de
controle, para garantir que nenhum dado foi extraviado ou adicionado durante
o processo; e

32
  Armazenamento dos documentos de origem em uma seqüência lógica, para
fácil recuperação.

4.3. Avaliação extensiva dos controles de sistema

A partir dos procedimentos para avaliação de cada grupo de controles

apresentados nos itens anteriores, deve ser elaborado um roteiro para avaliação extensiva
dos controles de sistema.

Os principais pontos que definem a adequação dos controles gerais são:

 Grau de comprometimento da administração com o projeto e a operação dos

sistemas:
 os métodos de supervisão e acompanhamento da administração e do
desempenho dos sistemas; e
 ações corretivas em relação às recomendações da auditoria interna e
reclamações dos usuários.
 Organização das funções dos sistemas, incluindo a atribuição formal das
responsabilidades e segregação de funções, no sentido de garantir que
funções críticas e responsabilidades de autorizar, processar, registrar e revisar
transações sejam atribuídas a diferentes indivíduos.
 Segurança física das instalações, especialmente quanto às restrições de
acesso.
 Segurança lógica (controle de acesso aos sistemas e dados através de senhas
e outros métodos) que ajudam a garantir a confiabilidade dos dados reduzindo
o risco de ocorrer entrada ou modificação não autorizada de dados.

33
 Os principais elementos que definem a adequação dos controles de aplicativos
são:

 Existência de procedimentos que garantam que os programas aplicativos e

suas modificações subseqüentes sejam autorizados e testados antes de sua
implementação.
 Freqüência das alterações no sistema e motivo de sua realização.
 Procedimentos adequados de controle e documentação das alterações nos
programas.
 Procedimentos de revisão, aprovação, controle e edição de dados de entrada,
para garantir sua integridade e prevenir erros.
 Existência de documentação e fluxogramas atualizados para os sistemas.
 Confrontação entre registros de saída e entrada (para confirmar que todos os
registros válidos de entrada foram processados, e somente esses).
 Procedimentos de detecção de erro e correção.
 Opinião dos usuários sobre a confiabilidade dos dados.
 Relatórios da auditoria interna e outros estudos de avaliação.

4.4. Avaliação moderada dos controles de sistema

O roteiro da avaliação extensiva pode servir de base para a elaboração do

programa de avaliação moderada, que deverá enfatizar os elementos-chave de controle, e
se direcionar, mediante o conhecimento prévio dos dados, para onde a ocorrência de falhas
é mais provável.

4.5. .Avaliação reduzida dos controles de sistema

Quando o conhecimento prévio dos dados indicar que a confiabilidade do sistema

já foi avaliada e considerada adequada em trabalhos anteriores, a avaliação dos controles
deverá se resumir à atualização das informações existentes. A equipe de auditoria deve
determinar se:

 alguma modificação foi feita no sistema após o trabalho anterior;

 os elementos-chave de controle ainda estão atuando;
 eventuais recomendações feitas sobre os controles do sistema foram
implementadas.

34
5. ESTUDO DE CASO
Nesta seção é apresentado um exemplo da aplicação dos procedimentos
mencionados neste módulo para determinar a confiabilidade de evidências processadas por
computador.

5.1. Situação hipotética

Uma equipe é designada para auditar a folha de pagamento da Empresa Pública

X, devendo determinar se:

 o pagamento dos salários está sendo feito de acordo com a legislação

pertinente;
 as deduções sobre os salários estão corretas, e foram transferidas para as
contas apropriadas;
 existem controles suficientes para garantir que não haja desvio de valores
destinados ao pagamento da folha.

5.2. Informações básicas sobre a área auditada

A Empresa X tem 500 funcionários, cuja folha de pagamento é preparada pelo

Setor de Pagamento do seu Departamento de Pessoal. O Setor de Pagamento usa um
sistema informatizado denominado “Folha de Pagamento” para o cálculo dos salários e
deduções. Esse sistema foi desenvolvido pelo Centro de Processamento de Dados (CPD)
da Empresa, e é administrado pelo Setor de Pagamento, que também é responsável por
solicitar ao CPD quaisquer alterações necessárias no sistema.

5.3. Procedimentos de avaliação

Uma vez que os dados que irão fundamentar o trabalho de auditoria deverão ser
extraídos do sistema informatizado “Folha de Pagamento”, antes de iniciar a auditoria
propriamente dita, a equipe de auditoria deverá proceder à avaliação da confiabilidade
desses dados.

O objetivo dessa avaliação é determinar se as declarações contidas no sistema

correspondem efetivamente à situação real auditada, respondendo à pergunta: “os dados
provenientes do sistema 'Folha de Pagamento', que serão utilizados como evidência para os
objetivos de auditoria, são confiáveis - completos e exatos?”

Aplicando-se os procedimentos indicados no capítulo 3 deste módulo, a

confiabilidade dos dados será avaliada com o propósito de obter-se uma segurança
razoável de que os dados do sistema “Folha de Pagamento” não contêm erros capazes de
comprometer a credibilidade das análises e conclusões da equipe de auditoria.

5.4. Determinação do uso planejado para os dados

Para determinar o uso planejado para os dados provenientes do sistema “Folha

de Pagamento”, a equipe deve analisar os seguintes pontos:

35
  Os dados serão realmente importantes para se atingir os objetivos de
auditoria? O sistema será utilizado apenas para estabelecer um histórico da
folha de pagamento, ou seus dados vão ser diretamente utilizados como
evidência nas conclusões do relatório?
 Os dados do sistema “Folha de Pagamento” são a única fonte de informação
sobre as despesas com o pagamento de pessoal, ou fazem parte de um
conjunto maior de evidências comprobatórias?

Nesse exemplo, será utilizada a hipótese de que os dados do sistema "Folha de

Pagamento" são os únicos capazes de fornecer as informações necessárias para a
realização da auditoria.

Tendo sido planejado o uso a ser feito dos dados processados pelo sistema
“Folha de Pagamento”, e identificada a necessidade de avaliação da sua confiabilidade
pode-se passar ao levantamento das informações disponíveis sobre esse sistema.

5.5. Levantamento dos elementos de conhecimento prévio sobre os dados

e o sistema

A equipe de auditoria deve formular questões como estas:

 O TCU utilizou esta mesma base de dados como suporte para achados de
auditoria em outros trabalhos recentes? Se a resposta for sim, qual foi a
avaliação da confiabilidade desses dados naquela ocasião?
 A Auditoria Interna da Empresa X avaliou recentemente o sistema, ou a
confiabilidade desses dados? Se a resposta for sim, qual foi a opinião emitida
sobre esses dados? Foram feitas recomendações para melhorar os controles
do sistema? O Departamento de Pessoal e o CPD adotaram as medidas
necessárias para implementar essas recomendações?
 O que os funcionários do Departamento de Pessoal e outros usuários do
sistema dizem sobre a exatidão dos dados? Com que freqüência eles
encontram erros nesses dados? Qual a importância desses erros?
 Os funcionários têm relatado problemas ou dúvidas quanto à exatidão dos
valores declarados no sistema? Eles confiam nos dados para desempenhar
suas funções, ou mantêm registros manuais em separado?
 Outras fontes de informação tendem a confirmar ou contradizer os dados
processados por computador?

5.6. Avaliação dos controle do sistema

A extensão dos trabalhos de avaliação dos controles do sistema vai depender do

resultado do levantamento anterior. Como os dados serão utilizados como única evidência,
a avaliação dos controles deverá ser extensiva ou moderada, dependendo das informações
obtidas sobre a confiabilidade do sistema ou dos dados (ver quadro 2).

A seguir, apresentam-se os procedimentos a serem adotados em cada situação:

5.6.1. Avaliação extensiva

36
 Hipótese: os dados do sistema “Folha de Pagamento” são os únicos disponíveis
como evidência para os objetivos de auditoria, e as informações conhecidas sobre o sistema
não permitem considerá-lo confiável.

A avaliação deve seguir os procedimentos indicados no capítulo 4 deste módulo,

abrangendo todos os aspectos dos controles gerais e de aplicativos

5.6.2. Avaliação moderada

Hipótese: determinada unidade do TCU utilizou informações da mesma base de

dados para fundamentar achados em relatório elaborado nos últimos 6 meses. Naquela
ocasião, a equipe concluiu que os controles do sistema eram eficientes, e que os dados
eram confiáveis.

Nessa situação, a avaliação extensiva dos controles do sistema não seria

necessária. A confiança no sistema seria determinada com base principalmente nas
informações conhecidas, associadas a um teste reduzido para indicar se:

 alguma modificação foi feita no sistema após o trabalho anterior;

 os elementos-chave de controle continuam operando;
 eventuais recomendações feitas sobre os controles do sistema foram
implementadas.

A avaliação dos controles do sistema concluirá com o parecer da equipe de

auditoria, que deverá classificá-los como sólidos, adequados ou fracos.

5.7. Determinação da confiabilidade dos dados

Com base na tabela do quadro 3, o risco de confiabilidade, no caso hipotético

aqui tratado, poderá ser classificado como alto ou moderado. Com a avaliação dos
controles, obtém-se o risco de confiabilidade ajustado, que poderá ser reduzido ou mantido
no mesmo nível, caso haja, respectivamente, uma avaliação positiva ou negativa dos
controles do sistema (quadro 4). Conhecendo-se risco de confiabilidade ajustado dos dados,
obtém-se, de acordo com o quadro 5, o grau de abrangência a ser atribuído ao teste de
dados.

5.8. Teste de dados

A seguir, apresentam-se os procedimentos que poderiam ser adotados nas duas

situações extremas possíveis (risco de confiabilidade alto, exigindo a execução de um teste
extensivo dos dados, e risco de confiabilidade baixo, autorizando a realização de um teste
mínimo). Em ambas situações, utilizou-se o método da “auditoria sem o auxílio do
computador”, possível nesse caso porque o resultado do processamento dos dados pode
ser manualmente verificado.

5.8.1. Teste extensivo

Hipótese: a equipe de auditoria determinou que:

37
  o sistema “Folha de Pagamento” é a única fonte disponível para os dados a
serem utilizados como evidência;
 nenhum trabalho do TCU ou do controle interno determinou recentemente a
confiabilidade desses dados;
 os controles gerais e de aplicação mostraram-se deficientes.

Nesse caso, o risco de confiabilidade é alto, e os resultados do teste de dados

por si sós deverão determinar a confiança nos dados. Assim, a abrangência dos testes será
extensiva, como indica o quadro 5.

Todos os testes deverão então ser executados em amostras estatisticamente

válidas (v. seção Técnicas de Auditoria do Manual de Auditoria do TCU), ou, se possível,
realizados em todos os registros, através de uma ferramenta automatizada de extração e
análise de dados.

O primeiro teste de dados consistiria na confirmação de que os dados de entrada

foram inseridos de forma exata e completa. Isso pode ser conseguido por meio dos
seguintes procedimentos:

 comparar o total de registros de entrada do computador com fontes

independentes (e confiáveis) da mesma informação (ex.: relação do pessoal
em atividade arquivado no Departamento de Pessoal; relatório da
Contabilidade que informe o número de funcionários que receberam salário no
mês investigado; etc.), para verificar se todos os funcionários que recebem
salário foram efetivamente cadastrados no sistema;
 para uma amostra válida de registros, fazer uma confrontação entre os
registros existentes no computador e as fontes primárias desses dados (ex.:
para a maioria dos campos, a fonte primária seria a pasta funcional do
servidor, onde poderia ser verificada a exatidão dos campos “tempo de
serviço”, "cargo" etc.), para averiguar se todos os campos importantes dos
registros foram preenchidos corretamente e qual a taxa de erro de entrada dos
dados no sistema.

Os próximos testes seriam projetados para avaliar a exatidão e integridade dos

dados de saída do sistema, podendo incluir:

 classificação dos registros em ordem alfabética dos beneficiários do

pagamento, para permitir a identificação de possíveis duplicatas e eventuais
discrepâncias entre a lista de nomes constante no sistema e a relação do
pessoal em atividade fornecida pelo Departamento de Pessoal;
 utilização de fórmulas para recalcular elementos de dados gerados pelo
computador (ex.: cálculo do valor do anuênio devido a partir dos dados
“vencimento básico” e do “tempo de serviço”), para confirmar a correção do
processamento efetuado nos dados de entrada;
 comparação do total de registros constantes no relatório final da folha de
pagamento com o total de registros de entrada, para garantir que todos os
dados de entrada foram processados e todos os funcionários cadastrados no
sistema estão presentes nesse relatório final;

38
  se os valores dos pagamentos informados pelo sistema estão dentro de
parâmetros “razoáveis” (não são quantias irrisórias ou extremamente elevadas)
e não extrapolam os limites legais;
 se a soma dos valores dos pagamentos mensais corresponde ao valor da
despesa com pagamento de pessoal declarado pelo setor de contabilidade da
Empresa.

5.8.2. Teste reduzido

Para uma pequena amostra de funcionários, deve-se comparar os registros

funcionais e de pagamento obtidos do computador com os documentos-fonte dessas
informações (formulários de entrada de dados no computador, fichas funcionais etc.).

Se esses testes básicos produzirem taxas significativas de erros, a abrangência

do teste deve ser expandida, utilizando-se os procedimentos indicados para o teste
extensivo. Se a taxa de erro for aceitável, baseada nessa atualização do trabalho anterior de
confiabilidade a equipe concluiria que os dados são confiáveis.

5.9. Conclusão

A partir do resultado dos testes de dados e das respectivas taxas de erro

encontradas, a equipe estará apta a avaliar a confiabilidade dos dados (que poderá ser
relatada de acordo com um dos modelos constantes deste módulo), e a iniciar os trabalhos
necessários para atender aos objetivos de auditoria.

39
MANUAL DE AUDITORIA DE SISTEMAS

PARTE 2 - AUDITORIA DE SISTEMAS

DE INFORMAÇÃO
1 CONTROLES GERAIS

Controles gerais consistem na estrutura, políticas e procedimentos que se

aplicam às operações do sistema computacional de uma organização como um todo. Eles
criam o ambiente em que os sistemas aplicativos e os controles irão operar.

Durante uma auditoria em que seja necessário avaliar algum sistema

informatizado, seja ele financeiro, contábil, de pagamento de pessoal etc., é preciso
inicialmente avaliar os controles gerais que atuam sobre o sistema computacional da
organização.

Controles gerais deficientes acarretam uma diminuição da confiabilidade a ser

atribuída aos controles das aplicações individuais. Por essa razão, os controles gerais são
normalmente avaliados separadamente, e antes da avaliação dos controles dos aplicativos
que venham a ser examinados em uma auditoria de sistemas informatizados.

Quando o objetivo da auditoria de sistemas informatizados é a avaliação de um

aplicativo específico (por exemplo, sistema de processamento da folha de pagamento de
uma entidade, ou de controle de empréstimos de uma instituição bancária), a equipe de
auditoria pode muitas vezes economizar tempo, antecipando atividades de auditoria, ao
planejar testes que avaliem controles tanto do ambiente geral quanto do aplicativo. Por
exemplo, como parte da avaliação dos controles gerais, a equipe irá testar controles que
abrangem alterações de programas.

Existem seis categorias de controles gerais que devem ser consideradas em

auditorias:
 controles organizacionais: políticas, procedimentos e estrutura
organizacional estabelecidos para organizar as responsabilidades de todos os
envolvidos nas atividades relacionadas à área da informática;
 programa geral de segurança: oferece a estrutura para: (1) gerência do risco,
(2) desenvolvimento de políticas de segurança, (3) atribuição das
responsabilidades de segurança, e (3) supervisão da adequação dos controles
gerais da entidade;
 continuidade do serviço: controles que garantem que, na ocorrência de
eventos inesperados, as operações críticas não sejam interrompidas, ou sejam
imediatamente retomadas, e os dados críticos sejam protegidos.
 controles de software de sistema: limitam e supervisionam o acesso aos
programas e arquivos críticos para o sistema, que controlam o hardware do
sistema computacional e protegem as aplicações presentes;
 controles de acesso: limitam ou detectam o acesso a recursos
computacionais (dados, programas, equipamentos e instalações), protegendo
esses recursos contra modificação não autorizada, perda e divulgação de
informações confidenciais;
 controles de desenvolvimento e alteração de softwares aplicativos:
previnem a implementação ou modificação não autorizada de programas.

41
 Para cada uma dessas seis categorias, este manual identifica os elementos
críticos que irão determinar a qualidade dos controles auditados e apresenta as técnicas e
procedimentos de auditoria recomendáveis para a avaliação desses controles.

De modo a facilitar a utilização dessas informações em auditorias, o manual

contém um roteiro que reúne todas as técnicas e procedimentos distribuídos nos diversos
itens. O roteiro apresentado deve servir apenas como referência para a equipe de auditoria,
que deverá determinar, em cada caso, quais as técnicas e procedimentos a serem aplicados
e a extensão dos testes a serem realizados, levando em conta o âmbito da auditoria e a
complexidade da organização auditada.

Além do roteiro apresentado a seguir a equipe de auditoria deve utilizar os

Procedimentos de Auditoria de Sistemas (PA-02) para planejar e executar um trabalho mais
completo e com maior nível de detalhe.

42
 1.1. Controles Organizacionais

1.1.1. Organização do departamento de tecnologia da informação

Como estabelecido no glossário de termos técnicos deste manual, o termo

"departamento de tecnologia da informação" (ou DTI) será utilizado para substituir o antigo
CPD (Centro de Processamento de Dados), representando o departamento responsável por
todos os serviços relacionados à área de informática, (redes de computadores, centrais de
telecomunicação etc.)

O DTI precisa ter uma estrutura organizacional bem definida, com as

responsabilidades de suas unidades organizacionais claramente estabelecidas,
documentadas e divulgadas, e políticas de pessoal adequadas, quanto à seleção,
segregação de funções, treinamento e avaliação de desempenho. Essa estrutura deve
gerenciar racionalmente os recursos computacionais da organização, de modo a suprir as
necessidades de informação de forma eficiente e econômica.

1.1.2. Segregação de funções

A segregação de funções tem como objetivo evitar que um indivíduo venha a

controlar todos os estágios críticos de um processo (por exemplo, um programador com
permissão para independentemente escrever, testar e aprovar alterações de programa).

Freqüentemente, a segregação de funções é alcançada pela divisão de

responsabilidades entre dois ou mais grupos organizacionais. Com essa divisão, a
probabilidade de que erros e ações indevidas sejam detectadas aumenta sensivelmente,
visto que as atividades de um grupo ou indivíduo irão servir para checar as atividades do
outro.

A ausência ou inadequação da segregação de funções de informática aumenta o

risco de ocorrência de transações errôneas ou fraudulentas, alterações impróprias de
programa e danos em recursos computacionais.

A extensão da segregação de funções a ser aplicada em uma organização irá

depender do seu tamanho e do risco associado às suas instalações e atividades. Uma
organização de grande porte terá mais flexibilidade em separar funções-chave que
organizações pequenas, que dependem de poucos indivíduos para executar suas
operações. Da mesma forma, atividades que envolvem transações financeiras de alto valor,
ou que de alguma outra forma são bastante arriscadas, devem ser divididas entre diversos
indivíduos e sujeitas a uma supervisão mais rigorosa.

Um exemplo de estrutura organizacional para o DTI, que permite uma adequada

segregação de funções, está ilustrado no quadro 6, a seguir.

Gerente de T.I.
(ou de Processamento de
Dados)
43
 Gerente de Operações Gerente de Suporte Gerente de Sistemas
Técnico

Supervisor de Líderes de Especialista Administrador Líderes de

Controle de Turno Técnico de Banco de Projetos
Dados Dados

Operadores Analistas/
Programadores

Quadro 6: Exemplo de estrutura organizacional para o Departamento de Tecnologia da Informação

(organização de tamanho médio)

Por causa da natureza da operação dos computadores, a segregação de funções

por si só não garante que somente atividades autorizadas sejam executadas pelos
funcionários, especialmente operadores de computador. Para auxiliar na prevenção e
detecção de ações não autorizadas ou incorretas, é também necessária uma supervisão
gerencial efetiva e procedimentos formais de operação.

Os elementos críticos para a avaliação dos controles organizacionais são:

 Unidades organizacionais bem definidas, com níveis claros de autoridade,

responsabilidades e habilidades técnicas necessárias para exercer os cargos;
 Atividades dos funcionários controladas através de procedimentos de
operação e supervisão documentados e políticas claras de seleção,
treinamento e avaliação de desempenho;
 Política de segregação de funções e controles de acesso para garantir na
prática a segregação de funções;
 Recursos computacionais gerenciados de forma a suprir as necessidades de
informação de forma eficiente e econômica.

A seguir é apresentado um roteiro contendo os elementos críticos dos controles

organizacionais.

1.1.3. Unidades organizacionais bem definidas

Foram definidas, para cada unidade organizacional do DTI:

 seus principais objetivos e padrões de desempenho;

 os diversos níveis de autoridade, as responsabilidades de cada cargo e as
habilidades técnicas necessárias para exercê-los.

44
Os funcionários do DTI:

 exercem atividades compatíveis com as estabelecidas formalmente pela

organização;
 possuem capacitação técnica compatível com o previsto no respectivo plano
de cargos.

1.1.4. Atividades dos funcionários controladas e políticas claras de seleção,

treinamento e avaliação de desempenho

Pontos a serem verificados:

 existem instruções documentadas para o desempenho das atividades dentro
do DTI, que são seguidas pelos funcionários;
 manuais de instrução indicam como operar softwares de sistema e
aplicativos.
 o pessoal tem supervisão adequada, inclusive nas trocas de turno de
operação de computadores;
 todas as atividades dos operadores do sistema computacional são
automaticamente armazenadas no registro histórico de operação;
 supervisores revisam periodicamente o registro histórico de operação, e
investigam qualquer anormalidade;
 a inicialização do sistema é supervisionada e executada por pessoal
autorizado e os parâmetros informados durante o carregamento inicial do
sistema operacional (initial program load - IPL) estão de acordo com os
procedimentos estabelecidos;
 é feito um planejamento das necessidades de pessoal especializado e
existem políticas definidas, métodos e critérios para o preenchimento de
vagas que permitem aferir as reais habilidades técnicas dos pretendentes;
 existe um programa de treinamento de pessoal na área de tecnologia da
informação, com recursos suficientes para capacitar o pessoal técnico;
 existe um programa de avaliação de desempenho eficaz.

45
 1.1.5. Política de segregação de funções e controles de acesso

Funções distintas são desempenhadas por diferentes indivíduos, incluindo as

seguintes:

 gerência dos sistemas de informação;

 projeto de sistemas;
 programação de aplicativos;
 programação de sistemas;
 teste e garantia de qualidade;
 gerência de biblioteca/gerência de alteração;
 operação de computador;
 controle de dados;
 segurança de dados;
 administração de dados.

A seguir estão destacados os principais pontos a serem verificados quanto à

política de segregação de funções em um DTI.

Nenhum indivíduo deve ter o controle completo sobre funções de processamento

incompatíveis (exemplos: entrada de dados e verificação da validade dos dados; entrada de
dados e conferência dos dados de saída; cadastro de notas fiscais e recebimento de bens,
e assim por diante). Observar as atividades dos técnicos para determinar se estão em
conformidade com a segregação de funções pretendida.

Os técnicos de processamento de dados e os gerentes de segurança não devem

estar encarregados de inserir dados ou executar transações nos sistemas de informação
que atendem às áreas-fim da organização.

Os procedimentos normais de operação do DTI são adequadamente

documentados e ações indevidas são identificadas.

São previstas rotações periódicas de pessoal e substituições no período de férias,

tendo em vista que indivíduos desempenhando funções incompatíveis e conduzindo ações
fraudulentas podem ser descobertos quando substituídos por motivo de férias ou rotação de
pessoal.

As descrições das atribuições dos cargos refletem os princípios de segregação de

funções. Examinar as descrições para uma amostra de cargos dentro da administração de
segurança e no grupo de usuários.

Todos os funcionários estão cientes de suas funções e responsabilidades, e

desempenham essas responsabilidades de acordo com as descrições do cargo. Entrevistar
ocupantes dos cargos cujas descrições foram examinadas. Verificar se as suas atividades e
responsabilidades conferem com o formalmente estabelecido.

A alta administração oferece recursos e treinamento adequados para garantir que

os princípios de segregação de funções sejam conhecidos, seguidos e institucionalizados
dentro da organização.
46
 As responsabilidades por restringir o acesso de funcionários em atividades
críticas de operação e programação foram claramente definidas, divulgadas e aplicadas.

Existem controles lógicos e físicos de acesso para auxiliar na restrição das

atividades dos funcionários às ações autorizadas, de acordo com as responsabilidades dos
respectivos cargos.

O desempenho dos funcionários é supervisionado periodicamente e controlado

para garantir que as atividades de cada um sejam compatíveis com as atribuições dos
respectivos cargos.

A alta administração realiza avaliações periódicas do risco, para determinar se as

técnicas de controle para segregação de funções estão funcionando como esperado e
mantendo o risco em níveis aceitáveis. Este procedimento deve ser executado em conjunto
com os previstos no item 2.1 - SEG-1.

1.1.6. Recursos computacionais gerenciados de forma eficiente e

econômica

As tarefas executadas pelo DTI obedecem a um cronograma adequado, de forma

a permitir que os recursos computacionais sejam utilizados com eficiência e que as
solicitações dos usuários possam ser atendidas. Entrevistar usuários e proprietários de
recursos computacionais para detectar eventuais distorções na alocação de recursos e/ou
conflitos causados por falhas no planejamento da distribuição da carga de trabalho.

A capacidade do hardware instalado é suficiente para atender a demanda nos

horários de pico e manter a qualidade do serviço para os usuários. Entrevistar usuários e
analisar os registros de utilização do hardware - log accounting - para detectar
desbalanceamento da configuração do sistema, pela caracterização de dispositivos -
unidades de disco, impressoras, terminais etc. - que estejam com folga ou sobrecarregados.

Existe um plano definido ou um acordo entre o DTI e os grupos de usuários,

quanto à disponibilidade dos recursos computacionais, com prioridades de processamento
adequadas às necessidades da organização.

Foram estabelecidas metas pela alta administração quanto à disponibilidade de

processamento de dados e serviços on-line.

A alta administração periodicamente avalia e compara os desempenhos de

serviço com as metas previstas e pesquisa junto aos departamentos usuários para saber se
as necessidades de disponibilidade dos sistemas estão sendo atendidas.

47
 1.2. Programa Geral de Segurança

O programa de segurança da entidade inclui suas políticas de segurança e o

respectivo plano de implementação.

Esse programa deve estabelecer uma estrutura para a avaliação do risco, o

desenvolvimento e implementação de procedimentos eficazes de segurança e a supervisão
da eficácia desses procedimentos. Sem um programa bem elaborado, os controles de
segurança podem ser inadequados, as responsabilidades podem não estar claras, não
serem compreendidas e propriamente implementadas, e os controles podem ser aplicados
de forma inconsistente. Tais condições podem levar a uma proteção insuficiente de recursos
críticos ou vulneráveis e, possivelmente, a um desperdício de recursos para implantação de
controles em situações de baixo risco.

1.2.1. Princípios da gestão da segurança

A gestão da segurança é regida pelos seguintes princípios básicos:

 Os dispositivos de proteção da segurança devem ser consistentes com a
vulnerabilidade dos dados que estão sendo protegidos.
 A proteção de segurança deve acompanhar os dados durante todas as etapas
do seu processamento e transmissão, e permanecer efetiva em todas as
situações.

Estes princípios são postos em prática determinando-se o grau de vulnerabilidade

dos dados1, sob o ponto de vista de sua integridade, caráter confidencial e disponibilidade, e
através da aplicação concreta de um Plano de Segurança que abranja os seguintes
aspectos de proteção: elemento humano, fatores físicos, práticas e procedimentos,
hardware, software, aplicações e elementos de apoio à segurança.

1.2.2. Avaliação do risco

Uma avaliação completa do risco deve ser o ponto de partida para o

desenvolvimento ou modificação do plano e das políticas de segurança da organização.
Essa avaliação é importante porque é através dela que se identifica todas as ameaças e
vulnerabilidades do sistema e se decide quais riscos serão aceitos e quais deverão ser
reduzidos através de controles de segurança.

A avaliação do risco deve considerar a vulnerabilidade inerente aos dados (ou

seja, sua susceptibilidade a erros materiais causados por omissão ou inserção incorreta ou
indevida de dados), e o risco adicional a que os sistemas e os dados podem estar sujeitos,
em função do seu uso por usuários internos e externos e eventuais tentativas de acesso por
estranhos não autorizados.

Essa análise deve também contemplar revisões da configuração do sistema e da

rede, e observação e teste dos controles de segurança já implantados. Ainda que o pessoal
envolvido em atividades de segurança possa oferecer uma visão valiosa sobre as
vulnerabilidades existentes, a avaliação geral do risco deve ser feita por pessoal
independente, para garantir sua objetividade.

1
V. termo "vulnerabilidade de dados" no Glossário deste manual.
48
 Avaliação do risco e gerência do risco são esforços contínuos. Ainda que a
avaliação geral do risco possa ser feita mais espaçadamente (a cada ano ou dois), o risco
deve ser reavaliado toda vez que houver mudança na operação da organização, ou em
influências externas que afetem essa operação.

1.2.3. Estrutura de segurança

As organizações de grande porte que possuam uma estrutura completa de

administração da segurança apresentarão os seguintes cargos, que podem assumir
diferentes denominações em cada caso:
 Superintendente de segurança: administrador sênior que tem a
responsabilidade final pela segurança da organização. Ele é o elo de ligação
com os outros órgãos e entidades da Administração e presta contas por todas
as questões de segurança dentro da organização.
 Diretor de segurança: gerente sênior, com autoridade delegada pelo
Superintendente de Segurança, com a responsabilidade de administrar as
questões rotineiras de segurança dentro da organização.
 Gerente de segurança computacional: gerente sênior, com autoridade
delegada pelo Superintendente de Segurança, que presta contas ao Diretor de
Segurança, tendo a responsabilidade de administrar a rotina da administração
da segurança das questões de informática e tecnologia de toda a organização.
 Equipe de segurança: grupo de indivíduos provenientes de diversos setores
da organização, designados para realizar o exame da segurança e efetuar
recomendações para a correção das vulnerabilidades detectadas. A equipe de
segurança deve preferivelmente ser chefiada por um membro influente do
grupo de usuários, de forma a que suas recomendações possam ser mais
facilmente aceitas pelos dirigentes e usuários, do que se partissem de
"especialistas técnicos".

Os elementos críticos que definem a qualidade dos controles do programa de

segurança são:

 Avaliação periódica do risco;

 Documentação do programa de segurança;
 Estrutura de gerência de segurança com atribuição clara de
responsabilidades;
 Políticas de segurança eficazes;
 Supervisão da eficácia do programa de segurança.

A seguir é apresentado um roteiro contendo os elementos críticos do Programa

de Segurança.

49
 1.2.4. Avaliação periódica do risco

Os riscos são periodicamente avaliados, de acordo com políticas documentadas

para essa avaliação.

As avaliações do risco são realizadas por pessoal suficientemente independente

(não diretamente responsável pelas questões de segurança), sendo revistas toda vez que
algum sistema, instalação ou outra condição se altere.

A avaliação do risco leva em conta a vulnerabilidade inerente dos dados, e o risco

adicional acrescentado pelos diversos caminhos de acesso passíveis de utilização por
usuários e estranhos não autorizados.

As avaliações gerais de risco mais recentes estão de acordo com as políticas

estabelecidas e atendem aos demais requisitos acima indicados.

1.2.5. Documentação do programa de segurança

O plano de segurança:
 foi documentado e aprovado pela alta gerência e pelos setores afetados;
 cobre todas as instalações e operações essenciais;
 é mantido atualizado, com revisões periódicas e ajustes que reflitam as
mudanças nas condições de operação e nos riscos.

1.2.6. Estrutura de gerência de segurança com atribuição clara de

responsabilidades

O plano de segurança:
 estabelece uma estrutura de gerência de segurança com independência,
autoridade e conhecimento suficientes;
 prevê a existência de gerentes de segurança dos sistemas de informação tanto
em nível geral quanto nos níveis subordinados;
 identifica precisamente o proprietário de cada recurso computacional e os
responsáveis pela gerência do acesso a esses recursos;
 define as responsabilidades de segurança nos seguintes níveis: (1)
proprietários e usuários dos recursos de informação; (2) pessoal de
processamento de dados; (3) alta gerência; e (4) administradores de
segurança;
 é periodicamente revisto e atualizado, estando em dia com as necessidades da
entidade.

50
 1.2.7. Políticas de segurança eficazes

Existe um programa de treinamento sobre as políticas de segurança, que inclui

treinamento inicial de todos os novos funcionários e usuários; e treinamento periódico de
atualização, e este está sendo seguido. Examinar os registros das atividades de
treinamento.

Entrevistas com o pessoal que utiliza recursos computacionais demonstram que

os funcionários estão cientes de suas responsabilidades quanto à segurança.

Os registros funcionais dos empregados que lidam com informações

confidenciais e/ou trabalham em funções de segurança demonstram que estes possuem o
conhecimento e a experiência requeridos na descrição dos cargos. Examinar uma amostra
de registros funcionais e compará-la com a descrição contida no plano de cargos.

A entidade exige dos funcionários e usuários externos com acesso a informações

confidenciais que assinem uma declaração de confidencialidade. Verificar as políticas de
acordo com confidencialidade e examinar uma amostra de registros para constatar se esses
usuários assinaram a declaração.

Não existem funcionários "proprietários" de informações críticas ou confidenciais

(há previsão de mudanças de turno ou trocas de função entre funcionários com acesso a
essas informações periodicamente, e as tarefas dos funcionários são redistribuídas durante
suas férias).

Os registros funcionais indicam que efetivamente é feito um revezamento de

pessoal nas tarefas de maior risco.

Os processos de transferência e demissão incluem procedimentos de segurança

tais como:
 devolução de crachás, chaves, passes de identificação, etc.;
 notificação da gerência de segurança para a pronta desativação de senhas de
acesso;
 imediata retirada do funcionário do local de trabalho;
 definição do período em que o funcionário afastado ficará sujeito à guarda do
sigilo das informações confidenciais às quais teve acesso.

1.2.8. Supervisão da eficácia do programa de segurança

A alta administração atua prontamente na correção de deficiências detectadas no

programa de segurança.

As ações corretivas são testadas após terem sido implementadas para confirmar
sua eficácia e, quando necessário, supervisionadas periodicamente. Verificar a situação das
recomendações mais recentes da auditoria interna e se as medidas corretivas adotadas
foram testadas quanto à sua eficácia.

1.3. Continuidade do Serviço

51
 A perda da capacidade de processar, recuperar e proteger informações mantidas
eletronicamente pode ter um impacto significativo na habilidade da organização em
desempenhar sua missão.

Por essa razão, as organizações precisam ter procedimentos estabelecidos para

proteger recursos de informação, minimizar o risco de interrupções não planejadas e
recuperar operações críticas, em caso de interrupções. Esses planos devem considerar as
atividades executadas nos ambientes de suporte em geral, tais como centros de
processamento de dados, bem como nos ambientes de operação de aplicações específicas.
Para se garantir que os planos de recuperação irão funcionar como previsto, eles devem ser
testados periodicamente em exercícios de simulação de "desastres".

Embora freqüentemente chamados de planos de recuperação de desastres, os

controles para garantir a continuidade do serviço devem enfocar todas as possibilidades de
interrupção existentes, sejam elas interrupções relativamente insignificantes, tais como falta
temporária de energia e destruição acidental de um arquivo, até problemas sérios, como
incêndios ou desastres naturais que requeiram o restabelecimento das operações em outro
local.

Se os controles não são adequados, mesmo interrupções menos graves podem

resultar em perda ou processamento incorreto de dados, ocasionando prejuízos financeiros,
esforços dispendiosos de recuperação e informações gerenciais ou financeiras inexatas ou
incompletas. Para algumas operações, tais como as que envolvem cuidados médicos ou
segurança pública, interrupções de sistema podem até mesmo resultar em danos pessoais
ou perda de vidas.

Para diminuir as interrupções de serviço, é essencial que os controles

estabelecidos sejam conhecidos e adotados pela gerência e pelo pessoal envolvido. O
comprometimento da alta administração é importante para garantir que recursos adequados
sejam dedicados para o planejamento de emergência, treinamento e testes necessários. O
pessoal responsável por atividades de manutenção da continuidade de serviço, tais como
realização de cópias de segurança de arquivos, precisa estar bem informado dos riscos da
não realização dessas tarefas.

Os elementos críticos para a avaliação da continuidade do serviço são:

 Avaliação da vulnerabilidade das operações computadorizadas e identificação

dos recursos que as apoiam.
 Adoção de medidas para prevenir e minimizar danos e interrupções
potenciais.
 Desenvolvimento e documentação de um plano geral de contingência.
 Teste periódico do plano de contingência e realização dos ajustes
apropriados.

A seguir é apresentado um roteiro contendo os elementos críticos da

Continuidade de Serviço.

52
 2.2.1. Avaliação da vulnerabilidade das operações computadorizadas e
identificação dos recursos que as apoiam

A organização preparou uma lista de dados, operações e sistemas críticos que:

 informa a prioridade de cada item;
 foi aprovada pelos gestores responsáveis;
 reflete a situação atual dos recursos computacionais.
Os recursos que dão suporte às operações críticas foram identificados e
documentados, incluindo hardware, software, fornecedores, documentação do sistema,
telecomunicações, instalações e suprimentos de escritório e recursos humanos.

As prioridades de processamento emergencial foram documentadas e aprovadas

pela alta administração e a gerência de processamento de dados.

1.3.2. Adoção de medidas para prevenir e minimizar danos e interrupções

potenciais

1.3.2.1. Procedimentos de cópia de segurança (backup)

Cópias de segurança dos arquivos e da documentação dos sistemas são

providenciadas e deslocadas para um local externo de armazenamento, com freqüência
suficiente para evitar problemas em caso de perda ou dano dos arquivos em uso.

O local externo de armazenamento está localizado geograficamente distante da

sede da organização e é protegido por controles ambientais e controles de acesso físico.

1.3.2.2. Controles de ambiente

Dispositivos de supressão e prevenção de incêndio foram instalados e estão em

funcionamento (detetores de fumaça, extintores de incêndio etc).

Controles físicos foram implementados para evitar outros desastres, tais como
inundação, elevação excessiva da temperatura etc. Os controles físicos são periodicamente
testados.

Foi providenciada uma fonte substituta de suprimento de energia elétrica que

permita, em caso de falha da fonte principal, a conclusão segura das operações em
andamento.

Bebidas, alimentos e outros itens que possam danificar os equipamentos são

proibidos no ambiente de computação. Verificar a existência e o cumprimento de normas de
procedimentos a esse respeito.

1.3.2.3. Treinamento do pessoal para responder a emergências

Os procedimentos de emergência são periodicamente testados.

53
 Os funcionários do centro de processamento de dados receberam treinamento
para os casos de emergência, tendo sido informados de suas responsabilidades na
ocorrência de eventos do gênero. Verificar se existem registros de treinamentos periódicos
previstos e efetuados, para procedimentos de emergência envolvendo fogo, inundação e
disparo de alarmes.

1.3.2.4. Medidas de prevenção de interrupções inesperadas

Existem políticas e procedimentos atualizados de manutenção de hardware,

gerência de problemas e gerência de alteração de programas para prevenir interrupções
inesperadas da operação.

Existe hardware de reserva que garanta, em casos de problemas com o

equipamento principal, a disponibilidade do sistema para aplicações críticas e vulneráveis.

Manutenções periódicas de hardware e software são programadas e executadas

de acordo com as especificações dos fornecedores, em circunstâncias que minimizem o
impacto na operação e na utilização pelos usuários, e permitam a realização dos testes
necessários.

Existe flexibilidade suficiente nas operações de processamento de dados para

acomodar a manutenção regular e um número razoável de manutenções não previstas.

Mudanças nos equipamentos de hardware e no software associado são

programadas de forma a minimizar o impacto da operação e utilização pelos usuários e
permitir a execução dos testes necessários.

As mudanças de hardware são informadas com antecedência para os usuários,

de forma a impedir que o serviço seja interrompido inesperadamente.

1.3.3. Desenvolvimento e documentação de um plano geral de contingência

1.3.3.1. Documentação do plano de contingência

Existe um plano de contingência devidamente documentado que:

 reflete as condições atuais da organização;
 foi aprovado pelos grupos mais afetados, incluindo a alta administração, DTI e
gerentes proprietários dos sistemas;
 atribui as responsabilidades de recuperação de forma clara;
 inclui instruções detalhadas para restaurar a operação, tanto do sistema
operacional quanto das aplicações críticas;
 identifica a instalação alternativa de processamento e o local externo de
armazenamento de cópias de segurança;
 inclui procedimentos a serem seguidos quando o centro de processamento de
dados estiver impossibilitado de receber ou transmitir dados;
 identifica os sistemas e os arquivos de dados críticos;
 é detalhado o suficiente para ser compreendido por todos os gerentes da
organização;
 foi distribuído para todas as pessoas apropriadas.

54
 O plano prevê pessoal substituto, de forma a poder ser implementado
independentemente de indivíduos específicos.

Os departamentos usuários possuem procedimentos de processamento manual

e/ou periférico para uso até a restauração da operação.

Pelo menos duas cópias do plano de contingência atualizado estão armazenadas

com segurança em diferentes locais.

O plano de contingência é periodicamente reavaliado e, se for o caso, revisto

para refletir alterações no hardware, software e pessoal.

1.3.3.2. Alternativas de processamento de dados e telecomunicação

Existem acordos com outros órgãos ou entidades para estabelecer um centro de

processamento de dados e de telecomunicação substituto, que:
 ofereça condições de operação num espaço de tempo compatível com os
riscos da operação interrompida;
 tenha capacidade suficiente de processamento;
 apresente grande probabilidade de estar disponível para uso em caso de
necessidade.

1.3.3.3. Teste periódico do plano de contingência, e realização dos ajustes

apropriados

O plano de contingência foi testado em condições que simulem um desastre.

Examinar as políticas de teste e os relatórios da sua execução.

Os resultados dos testes foram documentados e um relatório com as "lições

aprendidas" foi providenciado e encaminhado para a alta administração.

O plano de contingência e os acordos relacionados foram ajustados para corrigir

quaisquer deficiências constatadas durante o teste.

1.4. Controles de Acesso

Os controles de acesso têm o propósito de oferecer uma garantia razoável de que

os recursos computacionais (arquivos de dados, programas aplicativos, instalações e
equipamentos relacionados aos computadores) são protegidos contra modificação ou
divulgação não autorizada, perda ou dano. Eles incluem controles físicos, tais como
manutenção dos computadores em salas trancadas para limitar o acesso físico, e controles
lógicos (softwares de segurança projetados para prevenir ou detectar acesso não autorizado
a arquivos críticos).

Controles de acesso inadequados diminuem a confiabilidade dos dados

processados pelo sistema e aumentam o risco de destruição ou divulgação indevida de
dados. Os seguintes exemplos ilustram as possíveis conseqüências de tais vulnerabilidades:

 Obtendo acesso irrestrito a arquivos de dados, um indivíduo pode fazer

mudanças não autorizadas para ganho pessoal ou para obter informações
controladas. Por exemplo, uma pessoa poderia: alterar o número da conta de
55
 um pagamento, desviando um desembolso para ela mesma; alterar
quantidades de inventário, para esconder um furto; alterar uma quantia a
receber; obter informações confidenciais a respeito de transações ou
indivíduos.
 O acesso a programas aplicativos utilizados para processar dados permite a
modificação não autorizada desses programas, ou introdução de códigos de
programação mal-intencionados, que poderiam ser utilizados para obter
acesso a arquivos de dados, resultando em situações similares às indicadas no
item anterior. Por exemplo, um funcionário poderia alterar o programa de
cálculo dos salários e gerar um pagamento indevido para ele mesmo.
 Sem a presença de controles nos terminais ou equipamentos de
telecomunicação que permitem entrada nos sistemas computacionais da
entidade, um indivíduo pode obter acesso a informações confidenciais ou de
uso controlado que estejam em meios magnéticos ou impressos; substituir
dados ou programas; furtar ou danificar intencionalmente equipamentos e
programas de computador.

Os objetivos de limitação do acesso visam a garantir que:

 os usuários tenham acesso somente aos recursos necessários para

executarem suas tarefas;
 o acesso a recursos de alto risco, tais como softwares de segurança, seja
limitado a poucos indivíduos;
 os funcionários estejam impedidos de executar funções incompatíveis ou além
da sua responsabilidade.

Se esses objetivos são atingidos, o risco de modificação ou divulgação indevida

de dados pode ser reduzido, sem interferência nas necessidades práticas dos usuários. O
equilíbrio apropriado entre necessidades do usuário e requerimentos de segurança exige
uma análise cuidadosa da vulnerabilidade e importância de cada recurso de informação
disponível, em confronto com as tarefas executadas pelos usuários.

A implementação de controles de acesso apropriados exige primeiro a

determinação do nível e tipo de proteção adequados a cada recurso e a identificação das
pessoas que precisam ter acesso a esses recursos. Essas definições devem ser efetuadas
pelos proprietários dos recursos. Por exemplo, os chefes de departamentos precisam
determinar a importância dos seus programas e dados e que nível de acesso é apropriado
para o pessoal que usa o sistema informatizado para executar, avaliar e relatar as
operações do departamento. Da mesma forma, gerentes encarregados do desenvolvimento
e modificação de sistemas devem determinar a vulnerabilidade dos recursos de hardware e
software sob o seu controle e o nível de acesso necessário para os analistas de sistema e
programadores, e assim por diante.

Os elementos críticos que determinam a adequação dos controles de acesso são:

 Classificação dos recursos de informação de acordo com sua importância e

vulnerabilidade;
56
  Manutenção de lista atualizada de usuários autorizados e seu nível de acesso;
 Implantação de controles lógicos e físicos para prevenir ou detectar acesso
não autorizado;
 Supervisão do acesso, investigação de indícios de violação da segurança e
adoção das medidas corretivas apropriadas.

A seguir é apresentado um roteiro contendo os elementos críticos do Controle de

Acesso.

1.4.1. Classificação dos recursos de informação de acordo com sua

importância e vulnerabilidade

Existem políticas e procedimentos documentados para a classificação dos

recursos de informação pelos critérios de importância e vulnerabilidade dos dados.

Os proprietários dos recursos estão cientes dos critérios de classificação

estabelecidos e efetuaram a classificação dos principais recursos sob sua responsabilidade.

A classificação dos recursos foi baseada em avaliações de risco, documentada e

aprovada pela alta administração e é periodicamente revisada.

1.4.2. Manutenção de lista atualizada de usuários autorizados e níveis de

acesso

As autorizações de acesso são:

 documentadas em formulários padronizados e mantidas em arquivo
organizado;
 aprovadas pelo proprietário do recurso computacional;
 transmitidas para os gerentes de segurança de uma forma protegida.

Os proprietários dos recursos computacionais periodicamente revisam as

autorizações de acesso para verificar se continuam necessárias e adequadas.

O número de usuários autorizados ao acesso remoto dos sistemas é limitado e

justificativas para esse acesso são documentadas e aprovadas pelos proprietários dos
recursos (v. item 4.3.3 para controles adicionais de acesso remoto).

Os gerentes de segurança revisam as autorizações de acesso e discutem

quaisquer autorizações questionáveis com os proprietários dos recursos.

Todas as mudanças no perfil de segurança são automaticamente registradas e

revisadas periodicamente pela alta administração.

Atividades não usuais são investigadas.

A segurança é notificada imediatamente quando usuários do sistema são

demitidos ou transferidos.

As autorizações de acesso temporárias são:

 documentadas em formulários padrão e mantidas em arquivo;
57
  aprovadas pela gerência encarregada;
 comunicadas de uma forma protegida para o serviço de segurança;
 automaticamente desativadas após um período determinado.
Existem formulários padrão para documentar a aprovação para compartilhamento
de arquivos de dados com outras entidades. Examinar formulários e entrevistar os
responsáveis pela manutenção dos dados.

Antes do compartilhamento de dados ou programas com outras entidades, são

formalizados acordos que definem como esses arquivos e programas serão protegidos.
Examinar os documentos de autorização de compartilhamento e os acordos de segurança.

1.4.3. Controles lógicos e físicos para prevenção e detecção de acesso

não autorizado

Todas as ameaças significativas para a segurança física dos recursos mais

vulneráveis foram identificadas. Verificar a disposição física dos recursos.

O acesso físico é limitado aos funcionários que precisam rotineiramente dos

recursos computacionais, através de vigias, crachás de identificação, cartões magnéticos
para acionar portas de acesso etc. Observar os pontos de acesso às instalações durante a
hora de funcionamento e fora do expediente; verificar a lista de pessoas com acesso
autorizado às instalações quanto à adequação dos nomes incluídos.

A gerência revisa regularmente a lista de pessoas com acesso físico a

instalações críticas.

Existem obstáculos físicos para o acesso à sala de computadores, fitoteca e

outras instalações críticas.

Todas as entregas e retiradas de fitas magnéticas e outros meios de armazenar

dados são autorizadas e registradas.

Chaves, cartões magnéticos de acionamento de portas e outros dispositivos de

acesso de reserva (que não estão sendo usados pelos funcionários) são mantidos pela
gerência de segurança de forma protegida.

Visitantes em áreas críticas, tais como sala do computador central e fitoteca, são
formalmente registrados e acompanhados. Verificar o registro de entradas de visitantes;
entrevistar os vigias e responsáveis pela segurança; observar o trânsito de pessoas pelas
áreas críticas nos períodos dentro e fora do expediente normal.

Procedimentos adequados de abandono da área de risco em situações de

emergência e de retorno do pessoal após a normalização da situação impedem o acesso
de pessoal não autorizado às áreas críticas durante o evento (ameaça de incêndio e outros
que exijam a desocupação do local).

As senhas são:
 únicas para indivíduos específicos, não grupos;
 controladas pelos usuários e não sujeitas a divulgação;

58
  alteradas periodicamente (entre 30 e 90 dias);
 não apresentadas na tela durante sua digitação;
 compostas de pelo menos seis caracteres alfanuméricos e impedidas de
repetição antes de seis trocas pelo menos.

Existem restrições quanto ao uso de nomes e palavras facilmente desvendáveis

(analisar uma lista gerada pelo sistema de senhas em uso).

As senhas fornecidas para o primeiro acesso dos usuários são imediatamente

alteradas.

Códigos de identificação e senhas de uso compartilhado pelos funcionários não

são permitidos.

Os sistemas não permitem mais que três tentativas de log-on (entrada em

comandos para iniciar uma sessão) com senhas inválidas.

Uma relação do pessoal em atividade, periodicamente atualizada, é usada para

verificar automaticamente a lista de usuários autorizados do sistema para remoção da
senha de funcionários demitidos ou transferidos.

Contas de acesso inativas são supervisionadas e removidas quando deixam de

ser necessárias. Verificar as especificações do software de segurança, examinar uma lista
gerada pelo sistema de usuários inativos e determinar por que o acesso desses usuários
não foi cancelado.

Os usuários detentores de outros dispositivos de acesso, tais como códigos e

cartões magnéticos, têm consciência da necessidade de sua guarda cuidadosa; de que
estes não podem ser emprestados ou compartilhados; e de que sua perda deve ser
imediatamente comunicada aos responsáveis.

Identificação de caminhos de acesso: é feita uma análise dos caminhos lógicos

de acesso todas as vezes que ocorrem mudanças no sistema.

1.4.3.1. Controles lógicos sobre arquivos de dados e programas de software

Softwares de segurança são usados para restringir o acesso aos arquivos de

dados e programas.

O acesso aos softwares de segurança é restrito aos administradores de

segurança.

As sessões de acesso a sistemas via terminais de computador são terminadas

automaticamente após um período de inatividade do operador.

Os responsáveis pela administração da segurança configuram o software de

segurança para restringir o acesso não autorizado a arquivos de dados, bibliotecas de
dados, procedimentos de operação em lote (batch), bibliotecas de código fonte, arquivos de
59
segurança e arquivos de sistema operacional. Testar os controles tentando obter acesso a
arquivos restritos.

1.4.3.2. Controles lógicos sobre a base de dados

Controles sobre os gerenciadores de banco de dados (SGBD ou DBMS) e

dicionários de dados foram implementados para:
 restringir o acesso a arquivos de dados nos níveis de leitura de dados,
campos, etc.;
 controlar o acesso ao dicionário de dados usando perfis de segurança e
senhas;
 manter trilhas de auditoria que permitam supervisionar mudanças nos
dicionários de dados;
 prever formas de pesquisa e atualização de funções de aplicativos, funções de
SGBD e dicionário de dados.

O uso das facilidades de SGBD é limitado aos funcionários cujas atribuições

exigem esse acesso.

O acesso ao software, às tabelas de segurança do SGDB, e a perfis de

segurança do dicionário de dados é controlado e restrito ao pessoal autorizado.

1.4.3.3. Controles lógicos sobre acesso remoto

Um software de comunicação foi implementado para:

 identificar o terminal em uso, de forma a restringir o acesso por meio de
terminais específicos;
 checar IDs (códigos de identificação do usuário) e senhas para acesso a
aplicativos específicos;
 controlar o acesso através de conexões entre sistemas e terminais;
 restringir o uso de facilidades de rede em aplicações específicas;
 interromper automaticamente a conexão ao final de uma sessão;
 manter registros da atividade na rede;
 restringir o acesso a tabelas que definem opções de rede, recursos e perfis de
operador;
 permitir que somente usuários autorizados desconectem componentes da
rede;
 supervisionar o acesso discado, através do controle da fonte de chamadas, ou
pela interrupção da chamada e retorno da ligação para números de telefone
previamente autorizados;
 restringir o acesso interno aos softwares de telecomunicações;
 controlar mudanças nesses softwares;
 garantir que dados não sejam acessados ou modificados por um usuário não
autorizado, durante sua transmissão ou enquanto temporariamente
armazenados;
 restringir e supervisionar o acesso ao hardware de telecomunicações ou
instalações.

60
 Números para discagem remota não são publicados e são periodicamente
alterados.

Ferramentas de criptografia foram implementadas para proteger a integridade e

confidencialidade de dados e softwares vulneráveis ou críticos.

Existem procedimentos para apagar dados confidenciais e programas instalados

em recursos a serem descartados pela entidade (leiloados, doados etc.).

1.4.4. Supervisão do acesso, investigação de evidências de violações de

segurança e adoção de medidas corretivas

Trilhas de auditoria são mantidas e todas as atividades envolvendo acesso e

modificação de arquivos vulneráveis ou críticos são registradas.

Violações de segurança e atividades suspeitas, tais como tentativas frustradas de

entrada no sistema, são relatadas para a gerência e investigadas (examinar os relatórios
sobre atividades suspeitas).

Os gerentes de segurança investigam as violações de segurança e relatam os

resultados para a alta administração.

Medidas de disciplina são tomadas para corrigir as violações de segurança

detectadas.

Políticas de controle de acesso são modificadas quando violações de segurança

são detectadas.

61
 1.5. Controles de Software

Software de sistema é o conjunto de programas projetados para operar e

controlar as atividades de processamento de um equipamento computacional.

Normalmente, um software de sistema é utilizado para dar suporte e controlar

uma variedade de aplicações que possam ser executadas num mesmo hardware de
computador.

O software de sistema auxilia a controlar e coordenar a entrada, processamento,

saída e armazenamento dos dados relativos a todas as aplicações executadas no sistema.
Alguns softwares de sistema podem alterar dados e códigos de programa em arquivos, sem
deixar uma trilha de auditoria.

São exemplos de software de sistema:

 software de sistema operacional;
 utilitários de sistema;
 sistemas de bibliotecas de programas;
 software de manutenção de arquivos;
 software de segurança;
 sistemas de comunicação de dados;
 sistemas de gerência de base de dados (SGBD).
O controle sobre o acesso e a alteração do software de sistema são essenciais
para oferecer uma garantia razoável de que os controles de segurança baseados no
sistema operacional não estão comprometidos, prejudicando o bom funcionamento do
sistema computacional como um todo.

Se os controles nessa área forem inadequados, indivíduos não autorizados

podem utilizar o software de sistema para desviar dos controles de segurança, bem como
ler, modificar ou apagar informações e programas críticos ou vulneráveis. Softwares de
sistema com controles ineficazes podem ser utilizados, ainda, para neutralizar controles
presentes em programas aplicativos, diminuindo significativamente a confiabilidade da
informação produzida pelas aplicações existentes no sistema computacional, e aumentando
o risco de fraude e sabotagem.

As preocupações com o controle de software de sistema são similares às de

controle de acesso discutidas na seção 4 e de controle de mudança de software a serem
apresentados da seção 6. Entretanto, por causa do alto nível de risco associado com
atividades de software de sistema, a maioria das entidades possui um conjunto separado
de procedimentos de controle para essas atividades.

Os controles de software de sistema são avaliados através dos seguintes

elementos críticos:
 Acesso limitado ao software de sistema;
 Acesso e uso supervisionado do software de sistema;
 Controle das alterações do software de sistema.

62
 A seguir é apresentado um roteiro contendo os elementos críticos do Software de
Sistema.

1.5.1. Acesso limitado ao software de sistema

Existem políticas e procedimentos atualizados para a restrição do acesso ao

software de sistema.

O acesso ao software de sistema é restrito a um número limitado de pessoas,

cujas responsabilidades exijam esse acesso. (Programadores de aplicativos e operadores
de computador não devem possuir autorização de acesso ao software de sistema.)

Os documentos com justificativa e aprovação da gerência para o acesso ao

software de sistema são mantidos em arquivo.

O nível de acesso permitido aos programadores de sistema é periodicamente

reavaliado pelos gerentes para ver se a permissão de acesso corresponde às necessidades
de serviço. Verificar a última vez que o nível de acesso foi revisto.

1.5.1.1. Caminhos de acesso

O sistema operacional é configurado para impedir que os controles do software

de segurança e de aplicativos sejam ignorados. Testar os parâmetros do sistema
operacional para verificar se ele está configurado para manter a integridade do software de
segurança e dos controles de aplicativos.

Todos os acessos a arquivos do software de sistema são automaticamente

registrados.

Todas as senhas e códigos de entrada no sistema vindos de fábrica foram

substituídos.

Controles físicos e lógicos foram instalados para proteger os terminais com

acesso ao software de sistema, incluindo restrições ao acesso remoto a esses terminais.

1.5.2. Acesso e uso supervisionado do software de sistema

Existem políticas e procedimentos documentados e atualizados para o uso de

utilitários do software de sistema.

As responsabilidades no uso de utilitários de sistema foram claramente definidas

e compreendidas pelos programadores de sistema.

As responsabilidades pela supervisão do uso de utilitários de sistema estão

definidas e são exercidas pela gerência de informática.

O uso de utilitários de sistema é registrado em relatórios produzidos pelo software

de controle de acesso ou outro mecanismo de registro de acesso.

63
 Os registros de acesso ao software de sistema e aos seus utilitários são
periodicamente examinados pela gerência de informática, e atividades suspeitas ou não
usuais são investigadas.

Revisões gerenciais são efetuadas para determinar se as técnicas de supervisão

do uso do software de sistema estão funcionando como previsto e mantendo os riscos
dentro de níveis aceitáveis (avaliações periódicas do risco).

1.5.3. Controle das alterações do software de sistema

Existem políticas e procedimentos atualizados para identificar, selecionar, instalar

e modificar software de sistema, bem como identificar, documentar e solucionar problemas
com esse software.

A implantação de novas versões do software de sistema ou seus utilitários segue

procedimentos de segurança, que incluem:
 justificativa documentada para a alteração;
 realização de testes conduzidos num ambiente próprio e não no ambiente de
operação normal;
 parecer técnico sobre os resultados do teste;
 revisão dos resultados dos testes e das opiniões documentadas, pelo gerente
de T.I.;
 autorização do gerente de T.I. para colocar a nova versão do software de
sistema em uso.

Existem procedimentos para controlar alterações de emergência, incluindo a

forma de autorização e documentação das alterações de emergência, relatório do fato à
gerência e revisão da alteração por um responsável pelo controle dessas alterações.

1.5.3.1. Instalação do software de sistema

A instalação é programada de forma a minimizar o impacto no processamento de

dados, sendo comunicada com antecedência para os usuários.

A migração para o uso do novo software testado e aprovado é feita por um grupo
independente, responsável pelo controle da biblioteca.

Versões ultrapassadas do software do sistema são removidas das bibliotecas de

programas em uso.

A instalação de todo software de sistema é documentada e registrada, para

estabelecer uma trilha de auditoria e permitir a supervisão da gerência de informática.

O software de sistema conta com o suporte do fornecedor.

O software de sistema e sua documentação são mantidos atualizados. Entrevistar

a gerência e os programadores de sistema a respeito da atualização do software de sistema
e sua documentação, e examinar a documentação para constatar se as alterações mais
recentes foram incorporadas.

64
 1.6. Controles de Desenvolvimento e Alteração de softwares Aplicativos

Softwares aplicativos são projetados para executar determinado tipo de

operação, a exemplo do cálculo da folha de pagamento ou de controle de estoque.
Tipicamente, diversas aplicações podem operar dentro de um mesmo conjunto de software
de sistema.

Os controles sobre a modificação de programas aplicativos ajudam a garantir que

somente programas e modificações autorizadas sejam implementadas.

Sem um controle apropriado, existe o risco de que características de segurança

possam ser omitidas ou contornadas, intencionalmente ou não, e que processamentos
errôneos ou códigos fraudulentos sejam introduzidos. Por exemplo:
 um programador pode modificar código de programa para desviar dos
controles e obter acesso a dados confidenciais;
 a versão errada de um programa pode ser implementada, perpetuando
processamentos errados ou desatualizados;
 um vírus pode ser introduzido, prejudicando o processamento.
A principal preocupação deste item é com o controle exercido sobre os sistemas
de software em operação (programas que manipulam os dados financeiros e informações
utilizadas em auditorias, que sofrem a maior parte das alterações de software). Entretanto,
os mesmos riscos e controles se aplicam aos sistemas em desenvolvimento.

Os elementos críticos para a avaliação dos controles de mudança e

desenvolvimento de software são:
 Características de processamento e modificações no programa são
devidamente autorizadas
 Todos os softwares novos ou revisados são testados e aprovados
 Bibliotecas de controle do software
A seguir é apresentado um roteiro contendo os elementos críticos do Controle de
Alteração de Softwares Aplicativos

1.6.1. Características de processamento e alterações nos programas são

devidamente autorizadas

Foi desenvolvida uma metodologia de desenvolvimento de sistemas que:

 fornece uma abordagem estruturada de desenvolvimento, compatível com os
conceitos e práticas geralmente aceitos, incluindo o envolvimento ativo dos
usuários durante o processo;
 é suficientemente documentada, sendo capaz de oferecer orientação a
funcionários com diversos níveis de conhecimento e experiência;
 oferece meios de controlar mudanças nos requisitos de projeto que ocorram
durante a vida do sistema;
 inclui requisitos de documentação.
O pessoal envolvido no desenvolvimento e teste de software foi treinado para
utilizar a metodologia de desenvolvimento adotada pela entidade.
65
 Formulários de solicitação de alteração de software são utilizados para
documentar pedidos e autorizações de mudança.

As solicitações de alteração são submetidas à aprovação tanto dos usuários do

sistema quanto do DTI.

Os softwares de domínio público ou de uso pessoal são objeto de políticas

restritivas (é importante que a entidade tenha políticas claras com respeito ao uso de
softwares de domínio público ou de propriedade pessoal do funcionário no trabalho. Permitir
aos funcionários que utilizem seus próprios softwares, ou mesmo disquetes para
armazenamento de dados que foram usados em outro lugar, aumenta os riscos de
introdução de vírus, de violação de patentes e de processamento errado de dados, causado
pela utilização de programas inadequados).

1.6.2. Todos os softwares novos ou alterados são testados e aprovados

Foram desenvolvidos padrões para os testes de software, que indicam as

responsabilidades de cada parte envolvida (usuários, analistas de sistema, programadores,
auditores, controle de qualidade etc.).

Planos de teste são documentados e aprovados.

Testes da rotina alterada e sua integração com o sistema são executados e

aprovados de acordo com o plano de teste, utilizando um número suficiente de condições
válidas e inválidas.

Uma amostra suficiente de transações e dados é utilizada para representar as

várias atividades e condições que serão encontradas no processamento.

O ambiente de teste é diverso do ambiente real (de processamento) e os dados

reais não são usados no teste de alterações de programas, exceto para construir arquivos
de dados de teste.

Os resultados dos testes são revistos e documentados.

Alterações de programa são colocadas em uso somente após a aprovação formal

dos usuários e da gerência de desenvolvimento de sistemas.

Quando o sistema novo ou modificado é posto em operação, a documentação é

atualizada em relação ao software, hardware, pessoal de operação e usuários.

A gerência de informática e/ou os administradores de segurança periodicamente

revisam as alterações introduzidas nos softwares para determinar se os controles de acesso
e controles de alteração foram respeitados.

1.6.2.1. Alterações de emergência

66
 Existem procedimentos de alterações de emergência documentados.

As alterações de emergência são:

 documentadas e aprovadas pelo supervisor de operação;
 formalmente relatadas à gerência de operação para as providências
necessárias;
 aprovadas, ainda que depois de realizadas, pelos gerentes de
desenvolvimento proprietário do sistema.

Existem procedimentos padrão para distribuição de software novo ou alterado a

ser implementado.

Informações sobre a alteração, incluindo a data de sua realização, são fornecidas

para todos os setores que mantenham uma cópia do sistema.

1.6.3. Bibliotecas de controle do software

1.6.3.1. Identificação e inventário de programas

Existe um software de gerenciamento da biblioteca para:

 produzir trilhas de auditoria de alterações no programa;
 manter números de versão dos programas;
 registrar e relatar alterações de programa;
 manter informações sobre datas de criação de módulos em uso;
 manter cópias de versões anteriores;
 controlar atualizações paralelas.

1.6.3.2. Restrições de acesso à biblioteca

Bibliotecas separadas são mantidas para programas em desenvolvimento e

manutenção, programas em teste e programas em uso (em produção).

Códigos-fonte são mantidos em biblioteca própria.

O código em uso, código-fonte e cópias extras dos programas são protegidos por
software de controle de acesso e por características de segurança do sistema operacional.

1.6.3.3. Controle do movimento de programas e dados entre bibliotecas.

Um grupo independente de usuários e programadores controla o movimento de

programas e dados entre bibliotecas.

Reproduções do código do programa, antes e depois da alteração, são

arquivadas e comparadas para garantir que somente as mudanças aprovadas foram
implantadas.

67
2 CONTROLES DE APLICATIVOS
Controles de aplicativos são aqueles incorporados diretamente em programas
aplicativos, nas três áreas de operação (entrada, processamento e saída de dados), com o
objetivo de garantir um processamento confiável e acurado.

A avaliação dos controles de aplicativo deve sempre ser executada em conjunto

com a verificação dos controles gerais do sistema informatizado, bem como da legalidade
do processamento efetuado (isto é, se o seu produto final está de acordo com as leis em
vigor e se está acarretando ou não desvio de recursos públicos).

O presente módulo tem por objetivo apresentar os controles que devem ser
verificados em trabalhos de fiscalização que incluam a avaliação de um ou mais programas
aplicativos da organização auditada.

2.1. Controles da Entrada de Dados

Os controles desta categoria são projetados para garantir que os dados são
convertidos para um formato padrão e inseridos na aplicação de forma precisa, completa e
tempestiva.

Os controles de entrada de dados devem detectar transações não autorizadas,

incompletas, duplicadas ou errôneas, e assegurar que sejam controladas até serem
corrigidas.

2.1.1. Documentos ou telas de entrada de dados

Existem procedimentos documentados para a inserção de dados na aplicação.

Os documentos ou telas de entrada garantem a entrada de dados de maneira

exata e consistente.

Os campos de dados de preenchimento obrigatório são facilmente identificáveis

na tela.

Existem padrões para as telas de entrada, quanto à sua apresentação,

disposição dos campos e acionamento de teclas.

68
 2.1.2. Rotinas de preparação dos dados (batch)

Existem rotinas para a preparação dos dados a serem preenchidos em cada

documento.

Há pessoas claramente identificadas como responsáveis pela preparação,

revisão e autorização da entrada de dados.

Existem rotinas escritas para cada atividade do processo de preparação de

dados, com instruções claras e adequadas.

2.1.3. Autorização para entrada de dados

Nem sempre é possível se ter procedimentos de autorização antes da entrada de

dados. Em sistemas de entrada de dados on-line, são indispensáveis as rotinas de
validação de dados para compensar a ausência da autorização. O sistema deve checar
automaticamente se o usuário está cadastrado para usar aquele aplicativo e se os dados
por ele preenchidos satisfazem a certas condições.

A organização deve estabelecer rotinas que impeçam o uso não autorizado ou o

mal uso de microcomputadores ou terminais durante a entrada de dados.

As verificações abaixo indicadas devem ser utilizadas para entrada de dados

batch ou on-line:

 no caso de aplicativos em que a entrada de dados ocorre em terminais ou

microcomputadores, há procedimentos de segurança para o uso, manutenção
e controle de códigos de identificação do operador e do terminal ou estação de
trabalho.
 os códigos de identificação do operador e do terminal são checados no
processo de autorização de entrada de dados.
 existem procedimentos documentados para que, em caso de transmissão
eletrônica de documentos, a rota utilizada e os procedimentos de autorização
sejam registrados.
 os microcomputadores e terminais usados pela organização para a entrada de
dados estão localizados em salas fisicamente seguras.
 as rotinas de entrada de dados da organização asseguram que esta atividade
só pode ser executada por funcionários com determinado nível de acesso.
 as rotinas de entrada de dados da organização prevêem a gerência e
utilização de senhas para prevenir o uso não autorizado de
microcomputadores e terminais.
 existem números e códigos de identificação únicos e individuais para
possibilitar o controle do acesso aos dados.
 existem mecanismos de segurança para gerenciar o acesso batch a arquivos
de dados.

Verificações para aplicações com entrada de dados batch:

69
  a aprovação da entrada de dados está limitada aos indivíduos especificados
pela organização em documento escrito.
 o pessoal responsável pela autorização da entrada de dados não executa
outras tarefas incompatíveis pelo princípio da segregação de funções (v.
módulo de Controles Gerais, Controles Organizacionais - Segregação de
Funções - item 1.2.).

Na entrada de dados on-line deve ser verificado se:

 existem controles lógicos e físicos nos terminais e microcomputadores para

prevenção e detecção de entrada de dados não autorizados.
 foram instalados mecanismos de segurança para gerenciar a autorização de
acesso às transações on-line e aos registros históricos associados.
 os mecanismos de segurança da organização garantem que todas as
tentativas de acesso, com ou sem sucesso, são gravadas em logs que
registram data e hora do evento de acesso e identificam o usuário.

2.1.4. Retenção de documentos de entrada (sistema batch)

Os documentos originais devem ser retidos pela organização por um determinado

período de tempo com intuito de facilitar a recuperação ou reconstrução de dados.

Existem procedimentos documentados para retenção de documentos-fonte na

organização.

Os documentos ficam retidos por tempo suficiente para permitir a reconstrução de

dados, caso sejam perdidos durante a fase de processamento.

Os documentos são mantidos em arquivos organizados, para fácil recuperação.

O departamento que originou os documentos mantém cópias dos mesmos.

Somente as pessoas devidamente autorizadas têm acesso aos documentos

arquivados.

Existem procedimentos documentados para remover e destruir os documentos

quando expirado o tempo de retenção, e estes são obedecidos.

2.1.5. Validação dos dados de entrada

A organização deve estabelecer rotinas que assegurem que os dados de entrada

são validados e editados de forma a espelharem corretamente os documentos originais.

Existem procedimentos documentados que definem o formato dos dados para

assegurar a entrada de dados no campo correto e com o formato adequado.

Nas rotinas de entrada de dados existem informações de ajuda (help) para

facilitar a entrada de dados e reduzir o número de erros.

70
 Existem mecanismos para a validação, edição e controle da entrada de dados
(terminais inteligentes ou software dedicado a essa função).

Os campos essenciais para o correto processamento posterior dos dados são de

preenchimento obrigatório.

Existem rotinas para detectar, rejeitar e impedir a entrada de dados incorretos no

sistema.

A validação dos dados é executada em todos os campos relevantes do registro

ou tela de entrada.

As rotinas de validação de dados testam a presença de :

 códigos de aprovação e autorização;
 dígitos de verificação em todas as chaves de identificação;
 dígitos de verificação ao final de uma seqüência (string) de dados numéricos;
 códigos válidos;
 valores alfanuméricos ou numéricos válidos;
 tamanhos válidos de campo;
 campos combinados;
 limites válidos, razoabilidade dos valores ou faixa de valores válida;
 campos obrigatórios preenchidos;
 símbolos;
 registros de entrada completos;
 campos repetitivos, eliminando a necessidade da entrada dos mesmos dados
mais de uma vez.

A organização utiliza totais de controle de processamento em lote (batch),

gerados pelos terminais de entrada de dados ou pelo software dos microcomputadores,
para assegurar que todos os dados enviados em lote foram recebidos corretamente.

A rotina de entrada de dados da organização estabelece um registro histórico dos

dados, proporcionando uma trilha de auditoria.

2.1.6. Tratamento de erros

A organização deve estabelecer rotinas para correção e re-submissão de dados

de entrada incorretos.

Existem rotinas para identificação, correção e re-submissão de dados incorretos.

71
 A rotina de entrada de dados possui procedimentos automáticos ou manuais que
permitem que dados errôneos sejam prontamente corrigidos e re-submetidos;

Existe controle sobre os erros ocorridos na entrada de dados, sendo possível

identificá-los, juntamente com as medidas que foram tomadas para corrigi-los e o tempo
transcorrido entre a sua ocorrência e sua correção.

As mensagens de erro geradas pela rotina de entrada de dados são

suficientemente claras e fáceis de serem entendidas pelo usuário do terminal ou
microcomputador, facilitando a correção e a re-submissão dos dados.

2.1.7. Mecanismos de suporte para entrada de dados

A organização possui um grupo de controle responsável pelas seguintes

atividades:
 investigar e corrigir qualquer problema operacional no terminal,
microcomputador ou outro dispositivo de entrada de dados;
 assegurar que os procedimentos de reinicialização são executados de maneira
apropriada;
 monitorar as atividades de entrada de dados no terminal, microcomputador ou
outro dispositivo similar;
 investigar qualquer desvio dos procedimentos de entrada de dados pré-
estabelecidos.

Os recursos computacionais e humanos disponíveis para a entrada de dados

garantem que estes sejam inseridos tempestivamente.

2.2. Controles do Processamento de Dados

Os controles de processamento devem assegurar que todos os dados de entrada

sejam processados e que o aplicativo seja executado com sucesso, usando os arquivos de
dados, as rotinas de operação e a lógica de processamento corretos.

2.2.1. Integridade do processamento

Existem procedimentos documentados que explicam a forma com que os dados

são processados pelo programa aplicativo.

Os sistemas on-line estão protegidos contra a atualização simultânea de arquivos

por diferentes usuários.

Existem registros históricos (logs) que armazenam eventos ocasionados pelo

computador e seus operadores durante o processamento da aplicação, fornecendo uma
trilha de auditoria das transações processadas.

Os códigos de identificação do usuário, do terminal ou do microcomputador,

juntamente com os dados de data, hora e informação anterior à alteração (esta última
quando a relevância justificar) são mantidos em registros históricos.

72
 2.2.2. Validação do processamento

Dados incorretos são rejeitados pelo aplicativo.

Procedimentos de validação são executados em todos os campos relevantes ou

de preenchimento obrigatório, antes da gravação dos dados.

Em rotinas de arredondamento matemático há um controle do efeito provocado

por esse arredondamento.

2.2.3. Tratamento de erros do processamento

As rotinas de tratamento de erro devem ser capazes de identificar transações

com erros e suspender seu processamento sem afetar a execução de outras transações
válidas. Existem procedimentos documentados para identificação, correção e reinserção de
dados rejeitados.

As mensagens geradas pelas rotinas de tratamento de erro de processamento

são claras e objetivas.

Os arquivos temporários de dados rejeitados pelo sistema são controlados

adequadamente e geram mensagens de alerta para que estes dados sejam devidamente
revisados e corrigidos.

Existe controle sobre os erros ocorridos durante o processamento de dados,

sendo possível identificá-los, juntamente com as medidas que foram tomadas para corrigi-
los e o tempo transcorrido entre a sua ocorrência e sua correção.

2.3. Controles da Saída de Dados

Controles da saída de dados são utilizados para garantir a integridade e a correta

e tempestiva distribuição dos dados de saídas.

2.3.1. Revisão dos dados de saída

Os relatórios de dados de saída são revisados com relação à sua integridade e

exatidão antes da sua liberação para os usuários.

Existem procedimentos documentados para relatar, corrigir e refazer relatórios de

saída com erros.

A revisão dos relatórios de saída inclui o confronto das contagens de registros

com totais de controle para garantir que dados não foram inseridos ou omitidos
indevidamente.

2.3.2. Distribuição dos dados de saída

Cada relatório impresso é etiquetado para identificar o nome do produto, nome do

destinatário e data e hora de produção.

Existem procedimentos escritos que descrevem o processo de distribuição dos

dados de saída (relatórios impressos ou on-line).
73
 Existem listas de distribuição pré-definidas para todos os dados criados pela
aplicação. As listas de distribuição de dados são alteradas de acordo com as necessidades
da organização.

Os usuários são questionados periodicamente para determinar se os dados

produzidos continuam sendo necessários ou úteis.

Os relatórios impressos são entregues ao seu destino dentro dos prazos

estipulados.

Existe controle sobre os dados de saída apresentados na tela para os usuários,

impedindo adulterações.

Existe um registro histórico das informações sobre os dados de saída.

Existem procedimentos documentados para reportar e controlar os erros

ocorridos no processamento dos dados de saída.

Os usuários são comunicados sobre os erros dos relatórios recebidos.

São mantidos registros dos relatórios com erros.

Existe controle sobre os erros ocorridos em relatórios (batch ou on-line), sendo

possível identificar os erros, as medidas que foram tomadas para corrigi-los e o tempo
transcorrido entre a ocorrência do erro e sua correção.

2.3.3. Segurança dos dados de saída

A organização deve manter procedimentos para restringir o acesso aos relatórios

apenas ao pessoal autorizado.

Existem procedimentos documentados para classificar os relatórios como

confidenciais, críticos ou de acesso geral.

Existem procedimentos adequados que asseguram a segurança dos relatórios

considerados confidenciais pela organização.

Há procedimentos para restringir o acesso de dados confidenciais somente às

pessoas autorizadas.

Os usuários com acesso a relatórios confidenciais (impressos ou on-line) têm

conhecimento da necessidade de sigilo e tomam medidas adequadas para protegê-los.

Os relatórios confidenciais são claramente identificados ou marcados. Estes,

quando não são mais úteis à organização, são destruídos de forma adequada.

74
3. DESENVOLVIMENTO DE SISTEMAS

A auditoria do desenvolvimento de sistemas objetiva avaliar a adequação das

metodologias e procedimentos de projeto, desenvolvimento, implantação e revisão pós-
implantação dos sistemas produzidos dentro da organização auditada. Essa avaliação pode
abranger apenas o ambiente de desenvolvimento da organização ou prever também a
análise do processo de desenvolvimento de um sistema específico, ainda na fase de
planejamento, já em andamento ou após sua conclusão.

O desenvolvimento de um sistema de informação representa um investimento

que não pode ser assumido sem dados confiáveis e precisos sobre o custo do projeto, seus
benefícios e os riscos envolvidos. Todos os projetos de desenvolvimento de sistemas
precisam ter sido avaliados em profundidade, devendo ser precedidos de análises de
custo/benefício, capacidade de satisfação dos usuários e de atendimento aos objetivos da
organização, custos de desenvolvimento, medidas de desempenho, planos de
implementação, previsão de recursos humanos etc. São necessários, também, mecanismos
gerenciais que auxiliem a definição da prioridade dos projetos e permitam sua avaliação e
controle durante todo o processo de desenvolvimento.

O desenvolvimento de sistemas possui diversas fases de evolução que podem

ser separadas da seguinte forma: Planejamento; Elaboração do plano de desenvolvimento e
início do projeto; Organização do projeto; Elaboração do projeto de sistema; Revisão e
aprovação pelos dirigentes; Desenvolvimento e Implantação; e Revisão de pós-
implementação.

A seguir é apresentado um roteiro para auditoria em sistemas em

desenvolvimento, que irá permitir a avaliação do ambiente e do processo de
desenvolvimento de sistemas na organização auditada.

3.1. Fase 1: Planejamento

A organização:
 identifica as necessidades de informação ainda não atendidas e estabelece um
plano de ação para o desenvolvimento dos sistemas de maior prioridade;
 estabelece e documenta as metodologias de desenvolvimento a serem
adotadas;
 define e documenta as responsabilidades de todas as pessoas envolvidas no
desenvolvimento de sistemas.

75
 A organização possui uma estratégia de desenvolvimento de sistemas de
informação e elaborou um plano operacional consistente com essa estratégia,
estabelecendo a prioridade dos sistemas a serem desenvolvidos de acordo com sua
importância para o cumprimento da missão institucional.
Foi estabelecida uma metodologia de desenvolvimento de sistemas que:
 fornece uma abordagem estruturada de desenvolvimento, compatível com os
conceitos e práticas geralmente aceitos;
 prevê o envolvimento ativo dos usuários no processo de desenvolvimento de
sistemas;
 prevê o uso de técnicas atuais, tais como tecnologia de banco de dados, redes
de comunicação de dados, ferramentas CASE, linguagens de quarta geração,
prototipação etc.;
 é suficientemente documentada, sendo capaz de oferecer orientação a
funcionários com diversos níveis de conhecimento e experiência;
 oferece meios de controlar mudanças nos requisitos de projeto que ocorram
durante a vida do sistema;
 inclui requisitos de programação, documentação, padrões para usuários,
programadores, desenvolvedores de sistemas e operadores do centro de
processamento de dados;
 estabelece mecanismos de reavaliação, acompanhamento e controle em todas
as fases do processo, pela equipe e as gerências envolvidas, permitindo
redirecionar os trabalhos ou abandonar o projeto, quando se concluir que o
novo sistema não irá atender às necessidades da organização.

A organização definiu e documentou as responsabilidades de todas as pessoas

envolvidas no desenvolvimento de sistemas.

Foram estabelecidos padrões para os testes dos sistemas produzidos, com

indicação das responsabilidades de cada parte envolvida (usuários, analistas de sistema,
programadores, auditores, controle de qualidade etc).

O pessoal envolvido no desenvolvimento e teste de software foi treinado para

utilizar a metodologia adotada pela entidade e possui habilidades e conhecimentos
suficientes.

3.2. Fase 2: Elaboração do plano de desenvolvimento e início do projeto

O projeto é avaliado mais minuciosamente quanto a análises de viabilidade

técnica, custo/benefício etc. Sendo confirmada a conveniência do desenvolvimento do
projeto, a organização estabelece e aprova um plano de desenvolvimento ou modernização
do sistema específico, com elementos suficientes para permitir o seu projeto físico e lógico
na próxima fase (natureza e abrangência do sistema, requisitos de usuário que deverão ser
atendidos e outras informações relevantes).

É selecionada a equipe de projeto, que deve ter, no conjunto, habilidades e

conhecimentos suficientes para conduzir com sucesso as atividades de elaboração do
projeto físico e lógico, desenvolvimento e implantação do sistema.
O sistema a ser desenvolvido foi avaliado mais minuciosamente, tendo sido
realizadas análises abrangendo custo/benefício, estudo de viabilidade técnica, importância
76
da informação para os usuários e sua relação com os objetivos gerais e funcionais da
organização, custos de desenvolvimento, planos de implementação, previsão de recursos
humanos e demais elementos relevantes para a tomada de decisão.

A organização estabeleceu e aprovou um plano de desenvolvimento ou

modernização de sistema, com elementos suficientes para permitir o seu projeto físico e
lógico (identificando a natureza do sistema, requisitos de usuário que deverão ser atendidos
e outras informações relevantes).

O projeto objetiva atacar deficiências reconhecidas ou problemas sistêmicos da

organização.

As estimativas e análises feitas em relação a cronograma e custos são razoáveis,

e os benefícios esperados são atingíveis.

Foram reservados recursos suficientes para a completa realização do projeto.

Foi designada uma equipe de projeto, formada por representantes do grupo de

usuários e do DTI, e que possui, em conjunto, os requisitos de habilidade e conhecimento
necessários para desempenhar a tarefa.

3.3. Fase 3: Organização do projeto

A equipe de projeto, com base no plano de desenvolvimento aprovado, cria e

submete à gerência um plano de trabalho, informando a abrangência e conteúdo do projeto,
bem como os mecanismos de acompanhamento e controle (cronograma, datas-limite,
processo de supervisão e acompanhamento das etapas, medidas de desempenho etc.), de
acordo com o estabelecido na metodologia de desenvolvimento de sistemas.

A equipe de projeto definiu claramente a abrangência do projeto e o conteúdo do

sistema de forma coerente com os objetivos previstos no plano de desenvolvimento.

Os usuários concordaram com a abrangência e o conteúdo do sistema.

Foi elaborado o plano de trabalho, contendo os mecanismos de

acompanhamento e controle do processo (cronograma, datas-limite, processo de supervisão
e acompanhamento das etapas, medidas de desempenho), de acordo com a metodologia
de desenvolvimento de sistemas.

O plano de trabalho foi devidamente analisado e aprovado pela gerência de

planejamento (ou similar) e pelo DTI.

3.4. Fase 4: Elaboração do projeto do sistema

A fase de elaboração do projeto de sistema consiste na produção dos seus

projetos físico e lógico utilizando a metodologia de desenvolvimento de sistemas padrão de
organização .

A equipe de projeto define detalhadamente as especificações técnicas e

funcionais do sistema, da forma mais completa possível, e elabora o projeto de sistema de
acordo com essas especificações, levando em conta o ambiente de operação existente.

77
 A equipe de projeto elaborou os projetos físico e lógico do sistema e produziu um
documento que apresenta:
 características do sistema - físicas (plataforma, recursos exigidos) e funcionais
(atividades a serem executadas);
 restrições ou impedimentos que possam limitar sua implementação;
 tecnologias envolvidas (arquitetura do sistema, sistemas de segurança,
questões de integração, tais como interconectividade e interoperabilidade);
 abordagem adotada para o projeto, seus componentes mais importantes e
como eles deverão operar em conjunto para atingir os objetivos
organizacionais;
 relatórios de viabilidade técnica, análise de riscos e custo/benefício do projeto;
 controles preventivos e corretivos, e trilhas de auditoria para os pontos críticos
do sistema.

Os projetos físico e lógico estão dentro dos padrões adotados pela organização
no que diz respeito a hardware, software, sistema operacional e linguagem de programação.

Os relatórios de viabilidade técnica, análise de riscos e custo/benefício são

consistentes e confiáveis.

3.5. Fase 5: Revisão e aprovação pelos dirigentes

Os departamentos envolvidos revisam todos os documentos produzidos para

determinar se o projeto é adequado para atender às necessidades organizacionais e de
usuários; confirmam a exeqüibilidade do projeto dos pontos de vista tecnológico e
orçamentário; analisam o risco de atrasos ou extrapolação do orçamento e aprovam o
ingresso na fase de desenvolvimento.

A equipe de projeto submeteu aos superiores um relatório (ou documento similar)

para revisão e aprovação do projeto.

O gerente de TI analisou os documentos produzidos nas fases anteriores e

concordou com o seu conteúdo.

A área usuária aprovou o relatório da equipe do projeto, autorizando-a a seguir

para a fase de desenvolvimento e implantação do sistema

3.6. Fase 6: Desenvolvimento e Implantação

A equipe desenvolve (isto é, codifica, integra e testa) o sistema e avalia sua

qualidade.

Os usuários testam o sistema e aprovam ou não sua implantação (etapa também

conhecida como homologação).
O sistema aprovado é implantado, de acordo com planos detalhados de testes,
transição, implantação e operação.

78
 O sistema foi produzido de acordo com a metodologia de desenvolvimento
adotada pela organização e atende às especificações de projeto.

A documentação do sistema desenvolvido é apropriada, estando dentro dos

padrões adotados pela organização no que diz respeito a hardware, software, sistema
operacional e linguagem de programação, e contém descrição lógica, diagrama de fluxo de
dados, descrição de arquivos, modelo de relatórios e outros itens considerados relevantes
para o seu bom entendimento e controle.

Foram preparados manuais de operação, de usuário e de manutenção do

sistema, bem como um plano de treinamento dos futuros usuários.

3.6.1. Teste do sistema

Foi criado um plano detalhado para o teste do sistema, compatível com os

padrões de teste estabelecidos pela organização e respeitando as responsabilidades
definidas para cada parte envolvida (usuários, analistas de sistema, programadores,
auditores, controle de qualidade etc.).

Testes do sistema e de integração com outros sistemas foram executados e

aprovados de acordo com o plano de teste, utilizando um número suficiente de condições
válidas e inválidas.

Amostras suficientes de transações e dados foram utilizadas para representar as

várias atividades e condições que serão encontradas no processamento real.

O ambiente de teste é diverso do ambiente real e dados reais não são usados no
teste de programas, exceto para construir arquivos de dados de teste.

Os testes foram revistos, documentados, seus resultados analisados e aprovados

pelo DTI e pela área usuária do sistema.

Foi efetuado um teste de aceitação final junto a usuários selecionados.

As deficiências de desempenho foram devidamente corrigidas antes do sistema

ser considerado em condições de entrar em operação.

3.6.2. Implementação

O sistema desenvolvido é colocado em uso somente após a aprovação formal

dos usuários e da gerência de desenvolvimento de sistemas.

Quando o sistema novo é posto em operação, a documentação é atualizada em

relação ao software, hardware, pessoal de operação e usuários.

Existem procedimentos padrão para distribuição de software novo a ser

implementado.

3.6.3. Bibliotecas de controle

79
 As bibliotecas dos sistemas em desenvolvimento são independentes das de
sistemas em manutenção, testes e programas em uso.

Os códigos-fonte são mantidos em biblioteca própria.

3.7. Fase 7: Revisão de pós-implementação

A gerência de desenvolvimento de sistemas verifica o grau de satisfação dos

usuários com os sistemas implementados e checa se os requisitos iniciais do usuário foram
ou não satisfeitos.

Foram feitas avaliações de resultado do sistema desenvolvido, do atendimento

das necessidades e requisitos dos usuários e do seu grau de satisfação.

O sistema foi testado para verificar sua conformidade aos padrões de

desenvolvimento e implantação estabelecidos pela organização.

80
4. BANCO DE DADOS
Tradicionalmente, o termo banco de dados foi usado para descrever um arquivo
contendo dados acessíveis por um ou mais programas ou usuários. Os arquivos de dados
eram designados para aplicações específicas e o programa era projetado para acessá-los
de uma forma predeterminada. Essa abordagem, no entanto, oferecia muitas dificuldades,
caso os dados ou o programa tivessem que ser modificados.

Uma alternativa mais moderna é o acesso do banco dados por meio de um

sistema gerenciador de banco de dados (SGBD ou DBMS, do inglês Database Management
System).

Os SGBD surgiram para resolver problemas relativos a dados duplicados e

deficiências na integridade e segurança dos dados. Antes deles, à medida que um aplicativo
era desenvolvido, os dados necessários eram produzidos quase sempre em um formato
específico para aquele programa. Se, por exemplo, um sistema de pessoal era criado,
seguido por um sistema de folha de pagamento, era normal que os dois sistemas tivessem
cópias separadas de elementos de dados comuns. Dessa forma, os dados eram duplicados
e sua integridade ameaçada, já que as cópias de dados rapidamente perdiam o
sincronismo.

O papel do SGBD é manter e organizar os dados e torná-los disponíveis para

programas aplicativos, quando requisitados. O gerenciador de banco de dados é um
software complexo, que se responsabiliza também pela segurança e integridade dos dados,
eliminando diversas tarefas de administração que antes precisavam ser executadas pelos
aplicativos.

Os sistemas gerenciadores de banco de dados tornaram-se um requisito

essencial na maioria dos ambientes de tecnologia da informação. Apesar do alto custo de
sua instalação, suas vantagens costumam compensá-lo.

As principais funções desempenhadas pelo SGBD são:

 manter os arquivos que constituem o banco de dados;
 oferecer uma interface uniforme para usuários e aplicativos que utilizam os
dados;
 fornecer elementos de dados para aplicativos que os solicitem;
 diminuir a necessidade de que o aplicativo saiba como os dados são
armazenados (estruturas de arquivos e registros);
 manter a integridade dos dados, quanto ao seu conteúdo (validação) e
referência (dependência de um elemento na existência de outro);
 controlar o acesso aos dados por meio de mecanismos de segurança.
4.1. Dicionários de dados

Quando os dados são compartilhados por duas ou mais aplicações, como

acontece com os bancos de dados, é preciso manter um registro de todos os elementos de
dados disponíveis no sistema, suas características e como eles são usados pelos
programas aplicativos. Dicionários de dados foram desenvolvidos com esse objetivo.

81
 Normalmente, os Dicionários de Dados armazenam as seguintes informações
para cada elemento:
 descrição (nome dos elementos de dados, descrição do seu conteúdo);
 formato e estrutura dos elementos de dados;
 relação com outros elementos de dados;
 programas ou transações com acesso aos dados, e razão para esse acesso;
 relatórios de saída que contêm os elementos de dados.

4.2. Armazenamento de dados

O método usado para armazenar os dados fica a cargo do próprio SGBD e

depende do tipo de sistema adotado, que pode ser hierárquico, em rede ou relacional.

Os SGBD hierárquicos e em rede normalmente armazenam dados como uma

estrutura de registros vinculados por ponteiros. Eles oferecem acesso rápido, mas sua
manutenção é complexa.

Sistemas relacionais, os quais se baseiam em uma teoria matemática definida

pelo Professor Ted Codd, nos anos 70, armazenam registros de dados em tabelas. Cada
tabela é representada por um arquivo indexado. O relacionamento que existe entre registros
é mantido mediante o uso de campos de referências cruzadas das tabelas, as quais são
avaliadas durante o tempo de acesso aos dados. Isso significa que o sistema relacional é de
fácil manutenção, porém mais lento quanto ao acesso quando comparado aos sistemas
hierárquicos ou em rede.

4.3. Acesso ao banco de dados

O acesso a banco de dados é uma necessidade não só para programadores mas

também para usuários do sistema e gestores. A maioria dos gerenciadores de banco de
dados (SGBD) modernos oferecem diversos meios de acesso aos dados nele armazenados,
operando dentro de um esquema de controle de acesso bastante rigoroso.

Geralmente as consultas aos dados são feitas por um mecanismo interativo, por
meio do qual o usuário é instado a fornecer instruções sobre que dados estão sendo
requisitados. Esse mecanismo de solicitação de dados é freqüentemente específico para um
sistema, mas hoje há uma linguagem padrão ANSI chamada SQL, que foi projetada para
atender ao modelo de banco de dados relacional mencionado anteriormente.

A SQL (Structured Query Language, ou Linguagem de Consulta Estruturada),

interpretada pelo SGBD, exige apenas que o usuário defina quais os dados desejados,
dispensando-o de informar como encontrá-los. Isso, mais uma vez, facilita o trabalho de
desenvolvimento de aplicativos e representa uma das maiores vantagens do uso dos SGBD,
que é a independência dos dados.

4.4. Bancos de dados distribuídos

Normalmente o banco de dados é armazenado em um sistema computacional

único, estando disponível para usuários diretamente conectados a esse sistema, ou com
acesso via rede. Esse tipo de banco de dados, dito centralizado, muitas vezes satisfaz
completamente as necessidades da organização.

82
 Em algumas organizações, entretanto, existe a necessidade de acesso aos
mesmos dados em diferentes localidades. Uma solução alternativa seria instalar banco de
dados duplicados em cada localidade, com uma cópia de todos os dados ou apenas dos
dados locais. Isso oferece independência a cada localidade com relação à disponibilidade
dos dados, caso seja interrompido o acesso ao sistema central, mas acarreta problemas de
manutenção, integridade e duplicação dos dados.

A melhor solução, nesses casos, é o uso de um SGBD que permita um banco de

dados distribuído. Cada localidade participante executa uma cópia do SGBD, que coopera
com as demais por meio da rede e, para todos os efeitos, forma um sistema único.

Os dados que são compartilhados por meio da rede pelas diversas localidades
também são tratados pelo SGBD como um banco de dados único e completo. Os dados são
distribuídos pela a rede de acordo com as solicitações de cada localidade, aumentando a
velocidade do acesso.

Por exemplo, um vendedor poderia solicitar informações sobre todos os pedidos

dos clientes da companhia em que trabalha. O SGBD responderia juntando todos os
pedaços da informação espalhados pela rede e formando o conjunto de dados solicitado.

Os dados podem ser distribuídos de forma horizontal (por registros) ou vertical,

(por campos dentro de uma tabela), de acordo com a necessidade específica. A distribuição
do banco de dados evita a dependência de uma só máquina e a necessidade da duplicação
de dados.

Os banco de dados distribuídos são projetados para manter todas as vantagens

oferecidas pelos SGBD e funcionam, do ponto de vista do usuário, da mesma forma que um
banco de dados centralizado.

4.5. Administração de banco de dados

O tamanho e a complexidade das bases de dados exigem que as organizações

possuam um pessoal especificamente designado para cuidar de todos os aspectos da
administração do banco de dados (coletivamente chamados de administrador de banco de
dados). As tarefas do administrador de banco de dados incluem a manutenção de estruturas
e sub-estruturas de dados, do software de SGBD e programas relacionados, documentação
do banco de dados, verificação da compatibilidade de novos sistemas com o banco de
dados, procedimentos de cópias de segurança, registros históricos e recuperação de falhas
do banco de dados etc. O administrador de banco de dados é responsável, também, pela
manutenção de controles sobre os dados, podendo combinar responsabilidades que
abranjam procedimentos e controles, que em sistemas convencionais seriam normalmente
efetuados por pessoas diferentes. Quando esses procedimentos e controles estiverem muito
concentrados no administrador de banco de dados, é importante, para preservar a
adequada segregação de funções, que esse administrador seja impedido de obter acesso
não supervisionado às instalações computacionais e aos sistemas em operação, bem como
de iniciar transações.

4.6. Administração de dados

83
 Outro técnico que merece destaque no DTI é a figura do administrador de dados.
Este é responsável pelo controle de todos os tipos de dados que são manipulados pelo
banco de dados, do ponto de vista do seu significado, seu formato e relacionamento com
outros tipos de dados. Difere do administrador de banco de dados porque preocupa-se, não
com os elementos operacionais e de segurança do funcionamento do banco de dados, mas
com os dados propriamente ditos, garantindo, por exemplo, que o mesmo dado (com
mesmo conteúdo) não seja armazenado como elementos de dados diferentes. Ele conhece,
sobretudo, o negócio da empresa, enquanto que o administrador de banco de dados deve
ser especialista no software gerenciador do banco de dados. Assim, o administrador de
dados garante, em primeira instância, a uniformidade e coerência do banco de dados,
possibilitando que os dados sejam inseridos de forma lógica e ordenada, pois nada
adiantaria possuir um software de última geração se os elementos de dados fossem
definidos aleatoriamente.

A seguir, apresentam-se as técnicas de controle e os procedimentos de auditoria

que podem ser usados em atividades de fiscalização que tenham como objetivo avaliar os
bancos de dados da organização auditada, em complemento às verificações indicadas no
capítulo 1 - Controles Gerais.

4.7. Avaliação de Banco de Dados

A seguir é apresentado um roteiro para a avaliação de bancos de dados

4.7.1. Controles da administração de dados

Foram claramente definidas e documentadas as responsabilidades relacionadas

à administração de dados, tais como:
 coordenação da manutenção dos dados (definição, criação, exclusão e
propriedade dos dados);
 estabelecimento de políticas de acesso, confidencialidade e integridade de
dados;
 manutenção da documentação;
 coordenação entre administração de dados, usuários e programação de
sistemas;
 desenvolvimento e manutenção de padrões.
O pessoal responsável pelas atividades de administração de dados possui as
habilidades e conhecimentos técnicos necessários para executá-las.

A organização estabeleceu padrões e métodos para o desenvolvimento de

aplicações que utilizam bancos de dados.

As atividades de administração de dados são armazenadas em registros

históricos e periodicamente analisadas por um supervisor.

84
 4.7.2. Controles da administração de banco de dados

Foram claramente definidas e documentadas as responsabilidades relacionadas

à administração de banco de dados, tais como:
 projeto e manutenção da estrutura da base de dados;
 revisão e avaliação da confiabilidade do sistema gerenciador de banco de
dados;
 avaliação do pessoal encarregado das funções de banco de dados;
 treinamento do pessoal responsável pela administração de banco de dados;
 segurança de dados.

O pessoal responsável pelas atividades de administração de banco de dados

possui as habilidades e conhecimentos técnicos necessários para executá-las.

As atividades de administração de banco de dados são armazenadas em

registros históricos e periodicamente analisadas por um supervisor.

O plano de treinamento em linguagens de acesso a banco de dados é adequado.

4.7.3. Controles de acesso ao banco de dados e dicionário de dados

O uso das facilidades do gerenciador de banco de dados é limitado ao pessoal

com atribuições compatíveis com esse acesso.

Existem mecanismos para restringir o acesso a arquivos de dados e ao dicionário

de dados (senhas, tabelas e perfis de segurança), impedindo o acesso a pessoas não
autorizadas.

O acesso ao software e às tabelas de segurança do SGBD e aos perfis de

segurança do dicionário de dados é limitado.

Foram estabelecidos procedimentos de autorização de acesso ao banco de

dados, que são cumpridos.

São produzidos registros históricos de acesso e atualização, bem como trilhas de

auditoria que possibilitem investigar o acesso e atualização a elementos da base de dados.

O gerenciador de banco de dados controla o acesso simultâneo aos elementos

de dados e possui mecanismos para prevenir processamento incorreto nessas situações.

4.7.4. Controles sobre o conteúdo e alterações no dicionário de dados

Há consistência entre as estruturas de dados do banco de dados e do dicionário

de dados.

O dicionário de dados contém os elementos necessários, tais como:

 data de criação e última atualização;
 descrição de cada elemento de dados;
 chaves utilizadas;
85
  estrutura de cada elemento de dados (qual registro lógico contém o elemento);
 programas e sistemas que utilizam cada elemento de dados e de que forma.
Foram estabelecidos procedimentos para produção de cópias de segurança
(backup) e recuperação do dicionário de dados.

São mantidas trilhas de auditoria que permitam supervisionar mudanças nos

dicionários de dados.

A alteração e a criação de novos nomes de arquivos e descrição de dados são

controladas e seguem padrões e políticas predefinidos.

4.7.5. Disponibilidade e recuperação do banco de dados

A organização deve estabelecer políticas e procedimentos que garantam a

disponibilidade do banco de dados e sua pronta recuperação após a ocorrência de falhas
operacionais ou desastres. As técnicas e procedimentos indicados devem ser usados em
conjunto com as apresentadas no item 3 - Continuidade do Serviço, do módulo A2 -
Controles Gerais.

Os procedimentos de backup de hardware e software asseguram a

disponibilidade da base de dados para as aplicações consideradas prioritárias, em caso de
redução da capacidade de operação.

Existem nós ou caminhos alternativos de acesso para bancos de dados

acessados via rede.

Foram estabelecidos procedimentos para recuperação lógica e física do ambiente

de banco de dados, e são obedecidos.

Os procedimentos de recuperação são periodicamente testados e atualizados.

4.7.6. Integridade do banco de dados

Existem procedimentos para avaliar o desempenho do banco de dados.

O gerenciador de banco de dados apresenta elementos de controle sobre a

organização, o acesso e o compartilhamento de dados.

Existem mecanismos de controle sobre a integridade dos dados, das rotinas e do

dicionário de dados do sistema gerenciador de banco de dados.

O sistema gerenciador de banco de dados mantém um controle das mudanças

realizadas na base.

O gerenciador de banco de dados estabelece controles sobre atividades de

pesquisa, atualização de aplicativos, funções de SGBD e dicionário de dados.

86
5. REDES DE COMPUTADORES
Atualmente, é bastante comum que os usuários de um sistema estejam em um
local diferente de onde se encontram os recursos computacionais da organização. Isso
torna necessário o uso de mecanismos de transporte de informações entre diferentes
computadores e entre computadores e seus periféricos.

As redes de comunicação de computadores permitem às pessoas o acesso

instantâneo a dados e a usuários em diferentes escritórios ou localidades da organização.

Em resumo, as redes oferecem as seguintes facilidades:

 acesso compartilhado a dados, aplicações, impressoras e outros dispositivos;
 correio eletrônico;
 acesso a usuários e dispositivos remotos;
 redução do custo de software, por meio de licenças de multi-usuário;
 acesso e execução de processamentos em sistemas remotos.
Para o bom funcionamento da comunicação de dados são usados:
 arquivo log de comunicações, onde ficam registrados todos os blocos
transmitidos correta e incorretamente para efeito estatístico e para tentativas
de recuperação de dados transmitidos;
 software de comunicação de dados para verificações de protocolo de
transmissão, gravação do arquivo log de transações e para codificação e
decodificação de sinais de comunicação;
 protocolo de transmissão, que garante a recepção correta do bloco de
informações transmitido;
 software ou hardware para a realização de codificação e decodificação das
informações transmitidas.

O principal risco oferecido pelas redes é o de acesso não autorizado a dados e

programas da organização, que pode resultar em danos ou prejuízos intencionais ou
acidentais.

Existe uma grande variedade de software e hardware especializados em limitar o

acesso de indivíduos ou sistemas externos a uma rede de comunicação. Exemplos de
componentes de rede que podem ser usados para limitar o acesso incluem gateways ou
firewalls (dispositivos que restringem acesso entre redes, importantes para reduzir o risco
associado ao uso da Internet), monitores de teleprocessamento (programas incorporados ao
sistema operacional dos computadores para limitar o acesso) e dispositivos de proteção dos
canais de comunicação.

Em alguns casos envolvendo telecomunicação, não é possível ou prático

restringir o acesso à rede mediante controles físicos ou lógicos. Nesses casos, ferramentas
de criptografia podem ser usadas para identificar e autenticar usuários, bem como para
auxiliar na proteção da integridade e sigilo de dados e programas, quando estes se
encontram no sistema computacional; estão sendo transmitidos para outro sistema; ou
foram armazenados em meios removíveis (disquetes e outros).
A criptografia envolve o uso de algoritmos (fórmulas matemáticas) e combinações
de chaves (seqüências de bits) que servem para transformar uma mensagem em códigos
87
ininteligíveis para aqueles que não possuem a chave secreta necessária para decifrá-los,
mantendo assim o conteúdo do arquivo ou mensagem confidencial. Servem também para
fornecer uma assinatura eletrônica, a qual pode indicar se alguma alteração foi feita no
arquivo, garantindo sua integridade e identificando o autor da mensagem.

Além dos riscos associados à facilidade de acesso a dados e programas, a

auditoria das redes de comunicação de computadores deve contemplar os riscos relativos à
operação incorreta do sistema, perda de informações não protegidas por cópias de
segurança e outras situações que podem causar dano ou prejuízo à organização em função
do ambiente de rede.

A auditoria de redes de comunicação deve abranger os seguintes elementos

críticos:
 Gerência de rede: devem existir procedimentos e políticas para auxiliar a
gerência do ambiente de rede e padrões definidos para controle do hardware
e do software envolvidos;
 Segurança dos dados e da rede: devem existir mecanismos de controle de
hardware e software que garantam a segurança e integridade dos dados
mantidos no ambiente de rede e dos recursos físicos que a compõem; bem
como limitem e controlem o acesso a programas e dados;
 Operação da rede: a organização deve oferecer condições para uma
operação eficiente da rede, incluindo normas e procedimentos de treinamento
de pessoal, execução de cópias de segurança, avaliação da eficiência do
serviço e rotinas de recuperação da rede após interrupções inesperadas;
 Software de rede: a gerência de rede deve monitorar e controlar o software
de comunicação e o sistema operacional instalado.

A seguir, apresenta-se um roteiro que pode ser usado em atividades de

fiscalização que possuam como objetivo a avaliação de redes de computadores da
organização auditada, em complemento às verificações indicadas no módulo A2 - Controles
Gerais.

5.1. AVALIAÇÃO DAS REDES DE COMUNICAÇÃO DE COMPUTADORES

5.1.1. Gerência de rede

Foram estabelecidos objetivos de curto e médio prazos para o processamento de

dados distribuído da organização, definindo precisamente as configurações de hardware,
banco de dados, topologia de rede e interfaces de rede de comunicações.

A escolha da plataforma de rede para a organização foi precedida de uma análise

de custo/benefício fundamentada em elementos suficientes para justificar a alternativa
adotada.

88
 O plano de implantação de processamento em rede contempla:
 participação dos usuários;
 riscos da conversão dos sistemas;
 as diferentes necessidades de processamento dos usuários das diversas
localidades;
 testes de aceitação a serem executados pelo DTI (Departamento de
Tecnologia da Informação), pelo controle de qualidade e por usuários
selecionados.

Os procedimentos de controle do processamento em rede são testados e

avaliados periodicamente.

Existem procedimentos documentados que definem as atividades permitidas no

ambiente de rede.

Os procedimentos de operação da rede foram distribuídos aos usuários de cada

departamento.

Foi estabelecido um mecanismo para garantir a compatibilidade de arquivos entre

as aplicações, à medida que a rede cresce em tamanho e complexidade.

Foi estabelecida uma política de auditoria e de backup para a rede.

Existem procedimentos documentados e responsabilidades atribuídas para as

atividades de inicialização (start-up), supervisão e uso da rede, e recuperação de defeitos de
funcionamento do hardware.

O Departamento de Tecnologia da Informação possui políticas, procedimentos e

padrões documentados, atualizados e divulgados para o pessoal responsável, cobrindo as
seguintes áreas:
 descrição resumida de cada aplicativo rodando na rede;
 procedimentos de operação (tais como startup e shutdown);
 gerência de fitas e discos;
 cópias de segurança (backup);
 procedimentos de emergência;
 planejamento de contingência.

5.1.2. Segurança dos dados

Foram instituídos mecanismos para padronizar definições de dados

compartilhados e manter os dicionários de dados de uso comum.

Existem mecanismos eficazes de controle sobre mudanças feitas nos dados

compartilhados.

5.1.2.1. Integridade dos dados

89
 Existem controles para garantir que a integridade dos dados seja mantida durante
a transferência de dados na rede, tais como:
 procedimentos de autenticação de mensagens;
 mecanismos de garantia da exatidão e integridade da transmissão.

5.1.3. Segurança da rede

Os departamentos de usuários mantêm um inventário atualizado dos

equipamentos de rede que se encontram em seu local de trabalho e revisam periodicamente
a eficácia das práticas de segurança adotadas.

Os procedimentos de segurança são adequados para proteger os recursos físicos

da rede e a integridade do software do aplicativo e dos dados armazenados, e são
periodicamente revisados (v. itens 1.2. Programa Geral de Segurança e 1.4. Controle de
Acesso, do capítulo 1 - Controles Gerais).

O grupo responsável pela segurança da rede confere periodicamente se a

documentação de segurança está devidamente atualizada e reavalia, com a freqüência
suficiente, a adequação dos controles de segurança:
 do hardware de comunicação e estações de trabalho;
 do sistema operacional;
 dos aplicativos relevantes;
 dos dados considerados confidenciais.
Existe segregação de funções adequada entre gerência de rede e gerência de
segurança.

5.1.3.1. Controle do acesso

São mantidas trilhas de auditoria por períodos razoáveis, informando atividades

tais como:
 login/out (local, hora e data, identificação do usuário);
 tipo de acesso (discado, por estação de trabalho etc.);
 tentativas de acesso inválidas (local, hora e data, ID).
Os usuários somente conseguem acesso aos discos, volumes, diretórios e
arquivos para os quais possuem autorização.

Foram implantados controles de acesso aos terminais ou estações de trabalho e

todos os usuários são identificados por senhas individuais.

Os terminais e estações de trabalho são inabilitados após um determinado

número de tentativas de acesso não autorizado.

Foram estabelecidos perfis de acesso para os usuários, que definem os recursos,

dados, aplicações, transações e comandos autorizados, de acordo com as
responsabilidades dos respectivos cargos.

90
 5.1.3.2. Segurança de comunicação na rede

Os controles são adequados para prevenir:

 transmissão incompleta;
 roteamento incorreto;
 alteração não autorizada de mensagens;
 divulgação não autorizada de informações.
Os dispositivos de conexão da rede possuem controles de segurança, incluindo
pacotes de software e dispositivos de criptografia.

Existem controles de acesso e de implementação sobre as seguintes funções de

comunicação:
 mudança do ambiente de rede;
 acesso discado;
 registro histórico de atividade da rede;
 criptografia de dados.

5.1.4. Segurança física

A segurança física oferecida para servidores e equipamentos de comunicação e

conexão em rede é adequada.

Os servidores estão localizados em uma área com acesso restrito apenas ao

pessoal autorizado.

Os terminais e estações de trabalho possuem mecanismos de segurança física

que previnem a sua remoção não autorizada.

5.1.5. Plano de contingência

A organização desenvolveu um plano de contingência para a recuperação da

rede, que inclui:
 proteção de arquivos de dados;
 procedimentos para vários níveis de interrupções e emergências;
 procedimentos de recuperação de aplicações do sistema;
 lista de documentos e arquivos com cópias a serem mantidas em outro local.
O plano de contingência é testado em simulações periódicas.

91
 5.1.6. Operação da rede

Os procedimentos de administração e operação da rede estão documentados e

atualizados.

As responsabilidades de operação estão claramente definidas para todas as

posições e preservam o princípio da segregação de funções.

O DTI estabeleceu um acordo de nível de serviço com os usuários que define:

 disponibilidade da rede;
 tempo de resposta;
 requerimentos de backup;
 requerimentos de controle e segurança.
Existem procedimentos para a avaliação periódica da rede, quanto ao seu
desempenho, tempo de resposta e tempo de recuperação após falhas.

Existem procedimentos documentados para a administração de problemas e sua

solução, e estes indicam as responsabilidades dos fornecedores. Examinar os registros de
resolução de problemas e determinar se os problemas estão ocorrendo com freqüência
excessiva, se o tempo de resolução é razoável e se algum problema reportado é
conseqüência de falhas nos controles do sistema.

5.1.6.1. Falhas e interrupções de serviço

A configuração de rede impede que a ocorrência de uma falha em um de seus

pontos provoque a queda de toda a rede.

A rede contém mecanismos que minimizam o impacto provocado por uma falha
do sistema e existem procedimentos documentados para o retorno à operação, caso ocorra
uma interrupção inesperada do serviço.

Os procedimentos de recuperação da rede após interrupções inesperadas do

serviço são periodicamente testados e atualizados (se for o caso), e o pessoal responsável
está devidamente capacitado para executar as atividades necessárias de forma eficiente e
rápida.

5.1.7. Software de rede

O software de comunicação de rede contém mecanismos para armazenar

temporariamente mensagens destinadas a usuários provisoriamente desconectados e
retransmiti-las automaticamente quando a conexão for restabelecida.

92
 Existem procedimentos documentados tratando da manutenção de rotas de
comunicação normais e alternativas.

O software de rede apresenta rotinas de tratamento de erros e de supervisão do

desempenho.

Foram especificadas em contrato as manutenções preventivas e reparadoras da

rede.

5.1.7.1. Controle de alterações

Existem mecanismos de controle e registro das mudanças efetuadas no software

de rede.

Os procedimentos de alteração do software de rede são adequados e prevêem

mecanismos de supervisão e autorização.

De modo geral, os procedimentos de controle de alterações do sistema levam em

consideração o impacto para a organização, incluindo a disponibilidade do sistema, impacto
para usuários, eficiência do sistema e atualização da documentação e manuais.

Existem procedimentos adequados para informar, treinar e auxiliar o pessoal de

operações na implementação e suporte de mudanças no software de rede.

93
6. MICROCOMPUTADORES
Normalmente são chamados de microcomputadores os computadores de mesa
que compreendem um processador, discos rígido e flexível, monitor e teclado. Os
microcomputadores podem ser utilizados isoladamente ou estar conectados a uma rede,
com o propósito de compartilhar dados ou periféricos.

Os microcomputadores oferecem às organizações diversas vantagens quanto ao

aumento de eficiência e flexibilidade. Entretanto, em razão da necessidade de mecanismos
de segurança próprios, que diferem daqueles tipicamente instalados num centro de
processamento de dados, a organização também pode ficar exposta a riscos substanciais.

Exemplos dos riscos específicos associados aos microcomputadores:

 familiaridade - por causa da aparente simplicidade e facilidade de uso, existe o
risco de que o uso inadequado seja subestimado por usuários e pela gerência;
 custo - ainda que os microcomputadores em si possam ser considerados de
baixo custo, é importante levar em conta o custo dos softwares, periféricos e
manutenção, que pode elevar significativamente o custo de uma máquina;
 localização - microcomputadores normalmente estão localizados em escritórios
comuns, com pouca proteção contra furto, acesso não autorizado ou dano
acidental;
 softwares proprietários - apesar de ser mais barato adquirir programas do que
desenvolvê-los internamente, os softwares oferecidos pelo mercado muitas
vezes não apresentam mecanismos de segurança adequados;
 conexão com outros computadores - quando os microcomputadores são
usados como terminais de mainframes ou inseridos em uma rede de
comunicação de computadores, o seu uso não autorizado pode levar ao
acesso indevido a dados e programas de toda a organização.

Para que possa proteger-se contra esses riscos, a organização precisa adotar
políticas e procedimentos específicos quanto ao uso de microcomputadores pelos seus
funcionários, compreendendo padrões de hardware, software, aquisição, treinamento e
suporte, além dos controles gerais e de aplicativos.

Os microcomputadores precisam de controles específicos destinados a protegê-

los da perda de dados e programas por furto ou acidente (a ser evitada por restrições físicas
de acesso às máquinas, controles de software, tais como senhas de acesso e realização
periódica de cópias de segurança), e do furto de equipamentos (por meio de mecanismos
adequados de segurança no local de trabalho).

Os elementos críticos para a auditoria dos microcomputadores são:

 Controles do software em uso: destinados a garantir a consistência da

operação do software instalados nos microcomputadores, impedindo a
instalação de programas não autorizados, a alteração indevida do software
instalado etc.

94
  Segurança: controlam o acesso a recursos computacionais, dados e
programas, protegendo-os contra alterações indevidas, furtos, divulgação de
documentos sigilosos etc.
 Controles sobre a operação: protegem os recursos de microinformática
contra prejuízos e danos causados por falta de treinamento de pessoal e de
manutenção adequada.

A seguir, é apresentado um roteiro indicado para a auditoria na área de

microcomputadores, que deve ser complementado pelas investigações sobre controles
gerais e de aplicativos apresentados nos capítulos 1e 2 deste manual.

6.1. Controles do software em uso

A organização estabeleceu políticas, padrões e procedimentos documentados

para aquisição e uso de microcomputadores e do software associado, abrangendo também
dados sobre:
 desenvolvimento e teste de aplicativos;
 documentação;
 controles de entrada, saída e processamento;
 backup e recuperação de dados e programas;
 autorização para o uso de software, hardware e dados.

A organização mantém um inventário atualizado dos recursos de microinformática

(hardware e software), sua localização física, seus usuários, softwares em uso etc.

A aquisição de recursos de microinformática é precedida de análise de

custo/benefício e da compatibilidade dos mesmos com o ambiente já instalado.

O uso dos microcomputadores é supervisionado pelos gerentes de cada unidade.

Existem normas que proíbem a instalação de programas pessoais dos

funcionários nos microcomputadores da organização e mecanismos para prevenir e detectar
o uso ou instalação de programas não licenciados (software pirata).

A documentação do software de micro é mantida atualizada e em local seguro.

Os departamentos de usuários de micros possuem procedimentos documentados

para catalogar, armazenar e fazer cópias de segurança de arquivos de dados e programas,
e estes estão sendo seguidos.

6.2. Controles de Segurança

Os recursos de microinformática foram classificados de acordo com sua

importância e vulnerabilidade, de forma a permitir que os mecanismos de controle sejam
direcionados para a proteção dos recursos que ofereçam maiores riscos para a organização.

Existem mecanismos de identificação de usuários e verificação do nível de

acesso aos microcomputadores (códigos de identificação ou IDs, senhas individuais).
Os microcomputadores conectados à rede pública de comunicação têm
mecanismos de proteção contra acesso externo indevido.

95
 Códigos de identificação e senhas de uso compartilhado pelos funcionários não
são permitidos.

Os procedimentos para documentação e backup de programas, arquivos de

dados e aplicativos são adequados e estão sendo seguidos.

Os backups de dados críticos ou confidenciais são mantidos em local seguro.

O plano de contingência contempla o ambiente de microinformática (v. capítulo 1

- Controles Gerais, Continuidade do Serviço – Desenvolvimento e documentação de um
plano geral de contingência).

Os programas aplicativos são protegidos contra atualizações indevidas.

Os recursos físicos de microinformática contêm identificação única e são

inventariados.

São utilizados estabilizadores de energia ou outros dispositivos similares para

proteção dos microcomputadores.

A organização mantém em todos os seus micros programas anti-vírus em

versões atualizadas.

Os usuários de micro costumam submeter ao programa anti-vírus os disquetes

recebidos de ambientes externos à organização.

São oferecidos seminários, palestras ou cursos aos funcionários da organização

com intuito de conscientizá-los sobre a importância da segurança em ambiente de
microinformática.

Os funcionários da organização são conscientes dos riscos que envolvem os

microcomputadores e agem de forma a minimizá-los.

6.3. Controles sobre a operação

Os usuários de micro recebem treinamento adequado.

São programadas manutenções periódicas preventivas em todos os

microcomputadores da organização.

O conteúdo dos discos rígidos dos microcomputadores é supervisionado e

controlado.

Existe um centro de suporte ao usuário capaz de dar informações, tirar dúvidas

de utilização e registrar problemas com o processamento.

96
GLOSSÁRIO

Aplicativo ou aplicação: programa ou conjunto de programas de computador que efetua

uma ou mais tarefas aplicadas a um campo específico. Dependendo do tipo de tarefa para o
qual foi projetado, o aplicativo pode manipular texto, números, gráficos ou a combinação de
todos estes elementos.

Arquivo: coleção organizada de informações, preparada para ser usada com finalidade
específica e identificada por um nome.

Banco ou base de dados: (1) coleção de dados organizados. (2) conjunto de todas as
informações armazenadas em um sistema de computação.

Códigos-fonte: (1) arquivo (texto) ou instruções originais a partir das quais um programa é
criado; (2) representação textual de um programa ou procedimento.

Controle de acesso: recurso que permite bloquear acesso a dados, de pessoas não
autorizadas.

Controles de aplicativo: métodos e procedimentos contidos no software do aplicativo cuja

função é garantir autoridade para originar dados, exatidão dos dados de entrada,
integridade do processamento e distribuição dos dados de saída.

Controles gerais: controles aplicáveis a todos os processamentos executados em um

ambiente informatizado, visando garantir que o ambiente computacional como um todo seja
eficiente, eficaz, seguro e confiável. Estão relacionados à organização, projeto,
desenvolvimento, modificação e segurança dos sistemas.

Dados: (1) representação formalizada de fatos, conceitos ou instruções, adequada para

comunicação, interpretação ou processamento; (2) qualquer representação, tais como
caracteres, símbolos etc., a qual pode ser associado um significado.

Dados de teste: conjunto de dados escolhidos especificamente para testar um sistema.

DBMS: v. Sistema gerenciador de banco de dados.

Departamento de Tecnologia da Informação (DTI): termo utilizado para substituir o antigo

CPD (Centro de Processamento de Dados), representando o departamento responsável por
todos os serviços ligados à área de informática, tais como de redes de computadores,
centrais de telecomunicação, etc. Normalmente composto pelas seguintes categorias de
pessoal:
 Gerência de TI: divisão corporativa, chefiada por um Diretor Executivo.
 Divisão de desenvolvimento e suporte de aplicações: dedicada ao projeto,
desenvolvimento e manutenção de softwares aplicativos. Pode consistir em diversas
equipes de desenvolvimento, incluindo analistas de sistema, projetistas e programadores.
 Divisão de operações: setor chefiado pelo Gerente de Operações e
responsável pela organização e operação diária do hardware e dos sistemas em uso. Presta
serviço para as equipes de desenvolvimento de aplicativos e usuários de sistemas.
 Divisão de suporte de produção: intermediário entre usuários e pessoal de
operação e redes de comunicação, oferecendo suporte para a identificação e solução de

97
problemas e falhas do sistema. Essa divisão pode também ser responsável pela
administração de base de dados para aplicações.
 Divisão de software de sistema: o grupo de programação de sistema que
será responsável pela instalação e manutenção de software de sistema e dar suporte ao
resto do pessoal de TI e usuários em matérias técnicas. Eles garantem que os sistemas de
hardware e software operam com desempenho ótimo.
 Divisão de comunicação de dados: o grupo de comunicação de dados ou
rede oferece assistência e auxílio aos usuários do sistema que experimentem problemas de
teleprocessamento ou precisam comunicar com dispositivos ou usuários remotos. São
responsáveis pelo desenvolvimento e manutenção de toda a rede de comunicação da
entidade.

Dicionário de dados: repositório centralizado de informações sobre dados, como por

exemplo, seu significado, relacionamento com outros dados, origem, utilização e formato.
Auxilia os administradores de base de dados, analistas de sistemas e programadores no
planejamento efetivo, controle e avaliação do sistema, armazenamento e utilização dos
dados.

Documento-fonte: registro original que deverá ser convertido para linguagem

computacional.

Elemento de dado: item específico de informação que tem parâmetros definidos (exemplo:
número de CGC).

Elementos-chave de controle: pontos de controle que, num sistema, desempenham uma

função essencial para evitar ou detectar erros em fases decisivas dos procedimentos ou
operações.

Entrada de dados: método de introduzir dados em um computador para processamento,

normalmente via terminais ou micros.

Firewall: conjunto de componentes de hardware e software instalado entre redes com o

propósito de segurança. A implementação deste dispositivo pode prevenir ou reduzir
ataques ou invasões às bases de dados corporativas. Pode-se instalar firewalls entre as
sub-redes de uma rede interna ou firewalls externos para proteger a rede corporativa de
ataques vindos do exterior. O firewall é composto por duas partes: choke e gate. Ambas
podem estar no mesmo computador ou em computadores diferentes. Na configuração do
firewall é aconselhável desabilitar os serviços de rede não necessários para a organização.

Gateway: máquina ou conjunto de máquinas que fornecem serviços entre duas redes. São
dispositivos usados na tradução entre protocolos de aplicação.

Gerenciador de banco de dados: v. Sistema gerenciador de banco de dados.

Hardware: - (1) componentes físicos (equipamentos) de um sistema de processamento de

dados; (2) equipamento mecânico e eletrônico, combinado com software (programas,
instruções etc.) na implementação de um sistema de processamento de informações
eletrônicas.

Integridade de dados: (1) qualidade de resistência do dado a perdas ou a tentativas de

destruição ou alteração, acidental ou intencional; (2) qualidade dos dados mantidos em

98
computador de, em conjunto, representarem o universo completo dos dados originais em
que se baseiam.

Interconectividade: habilidade de conectar eletronicamente um equipamento. Por exemplo,

conectar-se a uma rede, enviar e receber dados.

Interoperabilidade: habilidade de sistemas trabalharem juntos, enviar e interpretar

mensagens, compartilhar dados etc.

Log: arquivo em disco ou fita no qual são registrados todos os fatos relevantes relativos ao
processamento de uma transação. Muito útil para a recuperação de informações para fins
de auditoria ou recuperação após falhas.

Nível de acesso: conjunto de características que define o tipo de atividade permitida pelo
usuário em um sistema computacional (ex.: somente consulta, entrada de dados, alteração
de configurações, etc.).

Plataforma: tecnologia base de um sistema de computação.

Projeto: aplicação de recursos materiais e humanos a um objetivo específico, mediante a

execução de uma seqüência pré-estabelecida de eventos, com princípio, meio e fim.

Projeto de sistema: fase de produção dos sistemas em que se elaboram os projetos físico
e lógico do sistema, com especificações detalhadas para o seu desenvolvimento.

Proprietário ou Gestor de dados ou sistema: setor responsável pela manutenção e

utilização de determinado sistema. Os proprietários devem ser os primeiros responsáveis
pela segurança dos seus dados

Recursos computacionais: elementos que fazem parte de um sistema computacional,

incluindo dados, programas, equipamentos e instalações.

Registro: grupo de fatos ou campos de informação relacionados entre si, tratados como
unidade.

Risco: efeito latente resultante da exposição de um sistema a uma situação à qual este é
vulnerável.

Risco de confiabilidade: (1) risco de que os dados utilizados não sejam suficientemente
confiáveis para o fim a que se destinam; (2) risco de que os dados não sejam exatos e
completos o suficiente para servir de fundamento para achados de auditoria.

Saída de dados: informação transferida a partir de um computador para o mundo externo.

99
Segurança computacional: conceitos e técnicas (medidas físicas, administrativas e
técnicas) usadas para proteger hardware, software e dados de um sistema contra dano,
destruição, acesso, manipulação, modificação, uso ou perda, decorrente de ação deliberada
ou acidental. O objetivo da segurança computacional é assegurar integridade e
disponibilidade do sistema e o sigilo das informações nele contidas.

Segurança de dados: prevenção contra acesso ou uso de dados por pessoal não
autorizado.

Segurança física: medidas de segurança para proteger os sistemas de informação, prédios

e equipamentos contra incêndio e outras intempéries naturais, ataques, invasão e acidentes.
Geralmente é feita através de controles administrativos, alarmes, trancas, crachás de
identificação etc.

Segurança física e lógica de um sistema: conjunto de salvaguardas tecnológicas e

administrativas estabelecidas e aplicadas para proteção de hardware, software e dados
contra alterações acidentais ou propositais ou, ainda, destruição.

Sistema: conjunto de processos ou elementos inter-relacionados, que funcionam juntos

para atingir um determinado resultado.

Sistema de processamento de dados: conjunto de equipamentos e programas de

processamento de dados capaz de aceitar informações, processá-las de acordo com um
plano e produzir os resultados desejados.

Sistema gerenciador de banco de dados (SGBD ou DBMS): programa projetado para

permitir a criação de arquivos especialmente organizados, bem como entrada, manipulação,
remoção e elaboração de um relatório dos dados existentes nesses arquivos.

Sistema on-line: sistema em que os dados são introduzidos no computador diretamente

pelo ponto de origem (o qual pode ser remoto ou local) e a saída é retornada imediatamente
a este mesmo ponto.

Software: conjunto de programas e instruções que operam o computador. São dois os tipos
de software de computador: software de sistema, o qual engloba operações básicas
necessárias para operar o hardware (por exemplo, sistema operacional, utilitários de
comunicação, monitores de performance, editores, compiladores etc.) e software aplicativo,
o qual executa tarefas específicas para auxiliar os usuários em suas atividades.

Teste: execução de um programa, processo ou rotina com intuito de identificar suas falhas.

Transação: conjunto de atividades.

Trilha de auditoria: (1) rotinas específicas programadas nos sistemas para fornecerem
informações de interesse da auditoria. (2) conjunto cronológico de registros que
proporcionam evidências do funcionamento do sistema. Estes registros podem ser utilizados
para reconstruir, revisar e examinar transações desde a entrada de dados até a saída dos
resultados finais, bem como para rastrear o uso do sistema, detectando e identificando
usuários não autorizados.

Usuário: qualquer pessoa que utiliza computadores e aplicativos.

100
Usuários de dados: funcionários ou terceiros que possuem direitos de acesso concedidos
pelos proprietários do sistema.

Utilitário: programa projetado para otimizar ou facilitar o trabalho com computadores,

reparar danos em software/hardware, ajudar a prática da programação, realizar
configurações, cópias de segurança, varreduras anti-vírus, etc.

Validação: (1) processo de avaliação de um sistema ou componente durante ou ao final do

processo de desenvolvimento, para determinar se este satisfaz os requerimentos
especificados; (2) processo de verificação dos dados de entrada de uma aplicação.

Vulnerabilidade da informação: qualidade ou condição da informação ser vulnerável,

determinada a partir da avaliação dos seguintes aspectos:
 disponibilidade: as informações, os serviços, os sistemas ou os programas
podem causar prejuízos se não estiverem disponíveis no momento oportuno?
 confidencialidade: a informação pode causar prejuízos se for divulgada?
 integridade: a informação pode causar prejuízos se for modificada, estiver
incorreta ou incompleta?

101
BIBLIOGRAFIA

PARTE 1 – Tecnologia da Informação e Atividade de Fiscalização

CIPFA (1997). Computer Audit. Londres, Reino Unido.

------ (1997). A Guide to Certification Audit. Londres, Reino Unido.

GAO (1991). Preparing, Documenting and Referencing Microcomputer Data Base

Applications. Washington-DC, EUA.

------ (1996). Assessing the Reliability of Computer Processed Data. Washington-DC,

EUA.

TCU (1996). Manual de Auditoria do Tribunal de Contas da União. Brasília-DF.

102
BIBLIOGRAFIA

PARTE 2 – Auditoria de Sistemas de Informação

AUDINET (1997). LAN Audit Program in ASAP – Auditor Sharing Audit Programs. Internet.

------ (1997). LAN Basic Audit in ASAP – Auditor Sharing Audit Programs. Internet.

CIPFA (1997). A Guide to Certification Audit. Londres, Reino Unido.

------ (1997). Computer Audit. Londres, Reino Unido.

GAO (1997). Assessing Risks and Returns: A Guide for Evaluating Federal Agencies'
IT Investment Decision-making. Washington-DC, EUA.

------ (1996). Assessing the Reliability of Computer Processed Data. Washington-DC,

EUA.

------ (1996). Federal Information System Control Audit Manual, Vol I - Financial
Statement Audits. Washington-DC, EUA.

------ (1996). The System Assessment Framework. Washington-DC, EUA.

GIL, Antônio de Loureiro (1993). Auditoria de Computadores. São Paulo: Atlas.

ICAS (1992). Auditing Small Computer Systems. Edinburgh, Escócia.

INTOSAI (1995). Information System Security Review Methodology.

------ (1996). IT Audit Training for INTOSAI. Barbados.

JENKINS, Brian (1992). An Audit Approach to Computers. London: Coopers & Lybrand.

TCU (1997). Procedimentos de Auditoria - Auditoria de Sistemas (PA-02). Brasília-DF.

103
RELAÇÃO DOS DOCUMENTOS ELABORADOS NA ÁREA DE FISCALIZAÇÃO E
CONTROLE EXTERNO

ESTRATÉGIAS ÚLTIMA
ATUALIZAÇÃO
Estratégia de Atuação para o Controle da Gestão Ambiental 1998

MANUAIS DE AUDITORIA ÚLTIMA

ATUALIZAÇÃO
Manual de Auditoria 1996
Manual de Auditoria de Desempenho 1998
Manual de Auditoria de Sistemas 1998
Manual de Instrução de Tomada de Contas Especiais 1997
Manual de Instrução de Tomada e Prestação de Contas 1997

PROCEDIMENTOS DE AUDITORIA ÚLTIMA

ATUALIZAÇÃO
PA-01 – Convênios 1998
PA-02 – Sistemas 1998
PA-03 – Licitações 1995
PA-04 - Contratos Administrativos 1995
PA-05 – Pessoal 1997
PA-06 - Obras Públicas 1998
PA-07 - Imóveis 1998
PA-08 - Publicidade e Propaganda 1998
PA-09 - Unidades Sediadas no Exterior 1998

ROTEIROS DE AUDITORIA ÚLTIMA

ATUALIZAÇÃO
Roteiro de Acompanhamento via SIAFI 1997
Roteiro de Extração de Dados do SIAFI 1998
Roteiro de Extração de Dados do SIAPE 1998

TÉCNICAS DE AUDITORIA ÚLTIMA

ATUALIZAÇÃO
Técnicas de Entrevistas para Auditorias 1998

OUTRAS PUBLICAÇÕES ÚLTIMA

ATUALIZAÇÃO
Convênios – Principais Informações para Estados e Municípios 1997
Auditorias do TCU nas Repartições do MRE no Exterior 1997

104
FOLHA DE SUGESTÕES

O TCU preocupa-se com o constante aperfeiçoamento da qualidade de seus

manuais e orientações, buscando, para isso, ouvir a valiosa opinião do público-alvo dos
referidos trabalhos.

O questionário a seguir refere-se especificamente ao Manual de Auditoria de

Sistemas, distribuído a partir de setembro de 1998. Será muito útil para o TCU se o leitor
deste manual puder dispor de alguns minutos para responder às perguntas elencadas no
referido questionário e enviá-lo aos Correios (não é preciso selar, o porte será pago pelo
TCU).

Sugestões sobre este manual também podem ser enviadas como se segue:

E-mail: saudi@tcu.gov.br
Fax: (061) 316-7538
Fone: (061) 316-7388
Endereço: Tribunal de Contas da União - TCU
SAUDI/DIPEA
Setor de Administração Federal Sul - Lote 01
CEP: 70042-900 – Brasília - DF

105
 Tribunal de Contas da União QUESTIONÁRIO DE AVALIAÇÃO
MANUAL DE AUDITORIA DE SISTEMAS

FINALIDADE
Este questionário tem por objetivo obter a opinião dos leitores sobre o Manual de Auditoria de Sistemas, com
vistas ao seu aperfeiçoamento.

Por favor, responda às questões abaixo assinalando com um “X” a alternativa mais adequada. Desde já
agradecemos a sua colaboração.

1. Em que esfera do governo você trabalha?

□ Federal □ Estadual ou DF □ Municipal
2. Em que órgão você trabalha?
□ Poder Legislativo □ Poder Judiciário □ Outro [especificar]
□ Poder Executivo □ Controle Interno
3. Que partes do Manual de Auditoria de Sistemas você leu?
□ Todo □ Itens 1,2 e 4 [todos ou parte] □ Itens 3 e 5 [todos ou parte]
4. Leia com atenção cada indicador e escolha o ponto da escala que melhor descreve a sua opinião sobre o
Manual de Auditoria de Sistemas. Marque com um “X” a opção que melhor representa o seu julgamento.
Concorda integralmente Concorda Indiferente Discorda Discorda integralmente
5 4 3 2 1

O manual é : 5 4 3 2 1
Fácil de ser lido □ □ □ □ □
Fácil de ser entendido □ □ □ □ □
Lógico □ □ □ □ □
Sucinto □ □ □ □ □
Completo □ □ □ □ □
Útil □ □ □ □ □
5. Como você tomou conhecimento do Manual de Auditoria de Sistemas?
□ Quando recebeu □ Pela Internet
□ Divulgação interna do TCU □ Pela imprensa
□ Por mensagem do SIAFI □ Outros [especificar]
6. Como você obteve o Manual de Auditoria de Sistemas?
□ Solicitou diretamente ao TCU □ Download pela Internet □ Outros [especificar]

7. Apresente, a seguir, comentários e sugestões para o aprimoramento da qualidade do Manual de Auditoria de

Sistemas. No caso de sugestões para alteração/supressão/aditamento de itens de verificação, favor preencher
o quadro anexo.

106
 Tribunal de Contas da União QUADRO DE SUGESTÕES
MANUAL DE AUDITORIA DE SISTEMAS

FINALIDADE

Nº do item Proposta de alteração, supressão ou aditamento Fundamentação

107
 PTR/BSB
880/92
UP-AC/TCU
DR/BSB

CARTA - RESPOSTA
NÃO É NECESSÁRIO SELAR

O SELO SERÁ PAGO POR

TRIBUNAL DE CONTAS DA UNIÃO
70099-999 BRASÍLIA-DF
UNIDADES DA SECRETARIA DO TRIBUNAL DE CONTAS DA UNIÃO
Secretaria da Presidência Olga Emília Monte Barroso
Assessoria de Cerimonial e de Relações Institucionais Márcia Paula Sartori
Assessoria de Imprensa Erivan Carlos de Carvalho
Assessoria de Relações Internacionais Sérgio Freitas de Almeida
Assessoria para Assuntos Legislativos Severino Lucena da Nóbrega
Consultoria-Geral Terezinha de Jesus Carvalho
Instituto Serzedello Corrêa Ricardo de Mello Araújo
Secretaria de Controle Interno Antônio Miranda de Castro
Secretaria-Geral das Sessões Eugênio Lisboa Vilar de Melo
Secretaria do Plenário Elenir Teodoro Gonçalves dos Santos
Secretaria da 1ª Câmara Francisco Costa de Almeida
Secretaria da 2ª Câmara Miguel Vinicius da Silva
Secretaria-Geral de Administração Antônio José Ferreira da Trindade
Secretaria de Engenharia e Serviços Gerais Mário Fabbris Riccó
Secretaria de Material, Patrimônio e Comunicação
Administrativa Leila Fonseca dos Santos V. Ferreira
Secretaria de Orçamento, Finanças e Contabilidade Pedro Martins de Sousa
Secretaria de Recursos Humanos Cláudia de Faria Castro
Secretaria-Geral de Controle Externo José Nagel
Secretaria de Auditoria e Inspeções Cláudio Souza Castello Branco
Secretaria de Contas do Governo e Transferências
Constitucionais Carlos Nivan Maia
Secretaria de Informática Antônio Quintino Rosa
Secretaria de Planejamento, Organização e Métodos Mauro Giacobbo
1ª Secretaria de Controle Externo José Moacir Cardoso da Costa
2ª Secretaria de Controle Externo Gilberto Fernando da Silva
3ª Secretaria de Controle Externo Sônia Lúcia Imbuzeiro
4ª Secretaria de Controle Externo Marília Zinn Salvucci
5ª Secretaria de Controle Externo Francisco Carlos Ribeiro de Almeida
6ª Secretaria de Controle Externo Antonio Newton Soares de Matos
7ª Secretaria de Controle Externo Cláudio Sarian Altounian
8ª Secretaria de Controle Externo Eduardo Duailibe Murici
9ª Secretaria de Controle Externo Jorge Pereira de Macedo
10ª Secretaria de Controle Externo Rosângela Paniago Curado Fleury
Secretaria de Controle Externo/AC Dion Carvalho Gomes de Sá
Secretaria de Controle Externo/AL Edimilson Monteiro Batista
Secretaria de Controle Externo/AP Wilson Maurício Paredes Ferreira Lima
Secretaria de Controle Externo/AM Helena Montenegro Valente
Secretaria de Controle Externo/BA Paulo Pereira Teles
Secretaria de Controle Externo/CE Paulo Nogueira de Medeiros
Secretaria de Controle Externo/ES Hamilton Caputo Delfino Silva
Secretaria de Controle Externo/GO Carlos Martins dos Santos
Secretaria de Controle Externo/MA Osmir da Silva Freire
Secretaria de Controle Externo/MT Luiz Guilherme da Boamorte Silveira
Secretaria de Controle Externo/MS Raimundo Nonato Coutinho
Secretaria de Controle Externo/MG Élsio Geová dos Santos
Secretaria de Controle Externo/PA José Márcio Paulino Murta
Secretaria de Controle Externo/PB Raimundo Nonato Soares Araújo
Secretaria de Controle Externo/PR Nazaré do Socorro do Rosário Vuardi
Secretaria de Controle Externo/PE Ildê Ramos Rodrigues Theodoro
Secretaria de Controle Externo/PI José Maria Araújo Lima
Secretaria de Controle Externo/RJ José Augusto Pôrto Neto
Secretaria de Controle Externo/RN Marcos Valério de Araújo
Secretaria de Controle Externo/RS Antônio José Martins de Almeida
Secretaria de Controle Externo/RO Fábio Arruda de Lima
Secretaria de Controle Externo/RR Rainério Rodrigues Leite
Secretaria de Controle Externo/SC Rafael Blanco Muniz
Secretaria de Controle Externo/SP Eloi Carnovali
Secretaria de Controle Externo/SE Clímaco Romualdo de Carvalho
Secretaria de Controle Externo/TO Jacques Silva de Souza