O processamento está entre a entrada e a saída de dados. É possível auditar o processamento dos dados analisando o código fonte dos sistemas ou a operação dos mesmos. Lembra-se que nem sempre o código fonte está disponível para ser auditado. Porém, mesmo disponível, a complexidade de rotinas e o volume destes códigos ao serem analisados exigiriam muito tempo para a auditoria ser completada. E, considerando que muitas rotinas podem estar em linguagem de programação diferente, isto demandaria ao auditor mais conhecimentos técnicos que o normal.
A segurança das informações pode estar comprometida por rotinas de processamento que foram alteradas de forma a gerar saídas diferentes para certas ocorrências pré-determinadas. O processamento dos dados é uma porta de manipulação indevida de dados de fácil implantação, pois uma rotina pode
simplesmente ser iniciada ou escondida por um simples comando de operação. Por esta razão é que o auditor deve, além de ser independente, ter certeza do comprometimento das pessoas que estão participando da auditoria, evitando prejudicar a eficácia da mesma.
Uma das maneiras do auditor conferir o processamento dos dados é por meio da análise das partes específicas do processamento manualmente e em paralelo, para confrontação dos resultados (DIAS, 2000). Mas, para que isto seja possível, ainda é necessário que o auditor tenha conhecimento lógico do processamento pretendido, ou seja, conhecimentos de contabilidade, administração, tributação, previdência, entre outros.
O resultado de um processamento é gravado, normalmente, no banco de dados, para posterior disponibilização. Tratando-se de uma intenção de fraudar dados, nem sempre os dados que são gravados são disponibilizados na saída, ocorrendo, então, um banco de dados paralelos, controlados por um processamento também paralelo.
Desta forma, se preciso for, o auditor deve inserir algumas rotinas de sua confiança entre o processamento, por um determinado tempo e região, para posterior conferência. Quando a auditoria for preventiva ou corretiva, o sigilo da mesma não é tão necessário, mas, quando esta for encomendada por suspeita de fraude, o sigilo é necessário, pois a divulgação de uma auditoria faz com que as pessoas comprometidas retirem rotinas de processamento fraudadoras dos sistemas, enquanto a auditoria está acontecendo.
Como visto, realizar auditoria no processamento dos dados não é uma tarefa simples, mas altamente necessária. Para a segurança das informações, o auditor não pode deixar esta área descoberta.
Saída de dados
A saída de dados é o resumo da entrada e o processamento. Se há erros na entrada e/ou no processamento, certamente a saída de dados ficará comprometida. Muitos erros que ocorrem na entrada ou no processamento somente são descobertos na saída de dados. É comum os erros na saída de dados serem descobertos apenas pelo usuário. Quando isso ocorre, já é tarde, e, provavelmente, os erros já estão gravados no banco de dados, comprometendo alguma parte dos dados por um determinado período de transação.
Alguns erros descobertos na saída de dados podem ter consequências tributárias ou previdenciárias, gerando valores a pagar a mais e multas e correções
financeiras, além da mão de obra necessária para a correção, podendo inclusive a empresa ficar sem operação, no todo ou em parte, por algum tempo.
Para não descobrir erros na saída de dados por intermédio do usuário, é necessário à equipe de desenvolvimento testar exaustivamente o sistema, principalmente na saída de dados. Esta tarefa, em alguns casos, é realizada, de forma muito simples ou viciada, pelo desenvolvedor. Aqui, este não testa a saída de dados com diferentes formas de entrada de dados e processamento.
Exemplo
O teste de uma rotina de cálculo de juros de uma conta sendo paga em atraso. O desenvolvedor sempre testa a diferença de dias entre as duas datas, a de vencimento e a de pagamento. Presume-se que a data de pagamento seja sempre posterior à data de vencimento. Na pressa, ou por falta de qualidade, o desenvolvedor sempre testa com duas datas válidas. O auditor deve testar esta rotina, por exemplo, com uma ou duas datas inválidas, ou ainda, com a data de vencimento sendo igual ou anterior à data de pagamento, para verificar se a rotina prevê estas condições errôneas. É que datas inválidas não podem calcular o montante de juros sem apresentar mensagem de erro.
Assim o auditor deve observar se a etapa de testes dos sistemas foi exaustiva, pois a pouca averiguação nos testes pode comprometer a segurança dos dados.
Destaque
A inexistência de erros na saída de dados não significa a inexistência de erros.
Somente uma auditoria completa e minuciosa pode afirmar a existência, ou não, de erros (DIAS, 2000). Desta forma, é conveniente que o auditor refaça manualmente uma operação de todo o processo de entrada, processamento e saída, para confrontar com as saídas do computador. Devido à integração de sistemas e necessidades de conhecimentos administrativos, tributários ou previdenciários, nem sempre essa tarefa é de fácil realização. Caso o auditor não detenha todos os conhecimentos necessários, ele deve ser assessorado.
Em alguns sistemas, as saídas de dados foram amparadas por legislação específica. Nestes casos, é preciso verificar a legislação em vigor para certificar-se de que as alterações, por ventura ocorridas, foram implantadas para a correta saída de dados.
Um dos pontos principais que afetam a saída de dados é a mudança de sistemas ou a integração com outros (DIAS, 2000). Caso isto esteja ocorrendo, ou, em curto espaço de tempo, tenha ocorrido, o auditor deve ser mais atento à auditoria na saída de dados. Concluindo, o auditor jamais pode deixar a saída de dados sem auditoria, pois esta é o resultado final de todo o aproveitamento dos recursos da Tecnologia da Informação que a empresa utiliza.