Durante seis anos trabalhei como IS Security Officer de uma multinacional, onde a área de Information Services era auditada ou tinha que fornecer informações e dados para auditores de outras áreas, em média, cinco vezes por ano. Ou seja, eu trabalhava inicialmente 45 dias por ano somente atendendo requisições de auditores e explicando como as coisas funcionavam dentro da empresa. Parece muito tempo para pouco retorno, porém o resultado de qualquer auditoria é o Audit Report que é discutido em um Draft e posteriormente apresentado em sua versão final durante o Exit Meeting.
Este documento tem uma grande força política dentro de qualquer organização que leve uma auditoria a sério, e pode causar desde um clima muito tenso dentro das áreas envolvidas até a demissão de um CIO. Ou seja, é necessário dedicar toda a atenção para o processo de auditoria, de forma a garantir que os resultados reflitam a realidade e possam ser discutidos com base em um entendimento comum de risco existente.
Eis a minha contribuição para encarar um cenário destes com o menor impacto possível:
- Guia de Sobrevivência para uma Auditoria de Sistemas (Parte 1)
- Guia de Sobrevivência para uma Auditoria de Sistemas (Parte 2)
