Segregação de deveres
Esta postagem é uma tradução automática da Postagem original em inglês do excelente site
https://www.aicpa.org/
Link desta publicação: Segregation of Duties
Segregation of Duties (SOD) is a basic building block of sustainable risk management and internal controls for a business. The principle of SOD is based on shared responsibilities of a key process that disperses the critical functions of that process to more than one person or department.
Segregação de deveres
A segregação de funções (SOD) é um bloco básico de gerenciamento de risco sustentável e controles internos para uma empresa. O princípio da SOD é baseado nas responsabilidades compartilhadas de um processo-chave que distribui as funções críticas desse processo a mais de uma pessoa ou departamento. Sem essa separação nos processos-chave, os riscos de fraude e erro são muito menos gerenciáveis.
Imagine o que aconteceria se as chaves, a fechadura e o código de um sistema de armas nucleares estivessem nas mãos de uma pessoa! Emoções, coerção, chantagem, fraude, erro humano e desinformação podem causar ações unilaterais graves e caras que não podem ser corrigidas. Ou considere o engenheiro de software que tem autoridade para mover o código para a produção sem supervisão, garantia de qualidade ou autenticação de direitos de acesso.
Sem SOD, qualquer um desses cenários mostra claramente a possibilidade de resultados desastrosos. Como resultado, a meta de gerenciamento de risco dos controles de SOD é evitar que ações unilaterais ocorram em processos-chave onde os efeitos irreversíveis estão além da tolerância da organização para erros ou fraudes.
Modelagem de controles de SOD
Dê uma olhada na Figura 1. A estrutura para SOD no desenvolvimento de um relatório de contabilidade e finanças pode ter esta aparência. As caixas com um 'X' representam as funções que não podem ser realizadas pela mesma pessoa. Por exemplo, o Engenheiro que desenvolve as consultas para um relatório não deve ser aquele que aprova a lógica ou a precisão dessas consultas.
Da mesma forma, a autorização de lançamentos contábeis manuais não pode ser realizada pela mesma pessoa que lança os lançamentos contábeis manuais a partir deste relatório. Este modelo simples fica mais complexo quando a fase de “Empurre para a produção” ou de gerenciamento de versão entra em ação.
SOD em Gestão de Risco
Cada organização tem uma certa tolerância ao risco. Riscos para empreendimentos bem-sucedidos, riscos de perdas por fraude ou erro, riscos de mercado e riscos jurídicos têm diferentes “curvas de preferência” em qualquer organização.
Uma curva de preferência mapeia uma relação entre a probabilidade de ocorrência de um risco e a quantidade de valor econômico em um ponto em que uma organização seria indiferente à ocorrência. Portanto, se a probabilidade de 50% de uma perda de $ 20.000 estiver na curva de indiferença para a Empresa A, então a empresa pode conviver com esse risco sem gastar recursos para criar controles para reduzir a probabilidade de ocorrência. O uso de conceitos de controle de SOD geralmente reduz o risco e ajuda a manter uma organização na preferência ou abaixo dela para um determinado tipo de risco.
Círculo de especialistas
Especialistas no assunto em direito corporativo, sistemas de informação e provedores de serviços forenses especiais usam ferramentas e estruturas de SOD ao gerenciar riscos de negócios em tecnologia por meio de auditoria. Aqui estão vários exemplos:
O e-Discovery é um desafio de gerenciamento de registros em que os princípios de SOD devem ser implementados e auditados para garantir a eficácia. Qual é a exposição ao risco se isso não for tratado adequadamente? Multas graves foram cobradas de empresas que não puderam cumprir intimações que contenham solicitações de documentação de acordo com as novas leis de descoberta eletrônica, incluindo a capacidade de manter protocolos de cadeia de custódia adequados. e-Discovery:
O gerenciamento de controles de acesso para direitos superadministrativos de sistemas operacionais (conhecido como acesso de nível “raiz”) é um desafio substancial para qualquer ambiente de controle de TI. Impede o acesso não autorizado aos principais sistemas e bancos de dados porque:
Use a função “funções e responsabilidades” nos aplicativos de software sempre que possível e mantenha uma pasta de trabalho do SOD de cada estrutura (como na Figura 1) para todos os processos-chave. Um controle organizacional avançado fará a interface do organograma de Recursos Humanos com a pasta de trabalho do SOD para criar um mecanismo de controle muito forte e uma ferramenta de gerenciamento simultâneo para alocar recursos e gerenciar orçamentos. Se as funções e responsabilidades não forem seguidas, a oportunidade de conluio não pode ser controlada dentro das preferências de risco de uma organização ou dentro de qualquer estrutura aceitável.
figura 1
Gerenciando Mudanças
O gerenciamento de mudanças nos ciclos de vida de desenvolvimento de software, operações de rede e departamentos de segurança de TI usa os conceitos de SOD para garantir aprovações adequadas e liberação para processos de produção. Existem cinco etapas básicas para todo o gerenciamento de mudanças que precisam de gerenciamento segregado e etapas de processo para manter um modelo de gerenciamento de risco adequado:
- início da mudança com a autorização apropriada.
- Supervisão de gerenciamento de projeto do processo de mudança.
- Acompanhamento de mudanças nas principais etapas do processo.
- Os controles de gerenciamento e risco correspondentes devem ser desenvolvidos e documentados.
- Supervisão de gestão e aprovação para implementação de mudanças na "produção".
Além disso, a descrição CoBIT (Objetivos de Controle para Informação e Tecnologia Relacionada) para push to Production ou Release Management deve ser bem compreendida: “ Além disso, os desenvolvedores de aplicativos não devem ser capazes de promover o código para a produção. Se esse controle não existir, podem ocorrer alterações não autorizadas no software. Além disso, alterações não controladas e / ou não autorizadas nas informações comerciais podem levar a fraudes e irregularidades. Finalmente, programas maliciosos podem ser introduzidos no ambiente de produção, afetando a disponibilidade do sistema, a integridade dos dados e os problemas de confidencialidade das informações. ”
Estudo de caso nº 1: Software de contabilidade e controle de sistemas operacionais: uma oportunidade para fraude
O gerente geral de uma rede de distribuição corporativa de equipamentos de refrigeração pesada descobriu que as contagens de estoque do sistema no software de contabilidade não correspondiam aos cálculos de estoque físico. Em geral, espera-se que a contagem do livro seja igual à contagem do inventário do sistema como uma verificação de auditoria básica para a precisão dos relatórios financeiros. A contabilidade do estoque contábil é baseada no último estoque físico conduzido em uma unidade de negócios. A contagem é usada como base para adicionar compras e subtrair o custo das vendas para calcular o estoque 'final' atual.
Mês após mês, o gerente de operações continuava apontando problemas no antigo software de contabilidade. A gerente de contabilidade continuou executando os cálculos do livro com variações em relação às contagens do sistema que ela não conseguia explicar. Para ajudar a resolver o problema, o gerente geral apresentou um caso de negócios aos executivos corporativos para um novo pacote de software de contabilidade integrado e solicitou suporte contábil do escritório corporativo para implementação. O software foi adquirido e a implementação foi rapidamente colocada em andamento para permitir a produção nos próximos meses.
Quando o inventário físico anual chegou, com vencimento no mesmo período anual, o gerente geral determinou que as avaliações de estoque do sistema deviam ser iguais às avaliações de estoque contábil no início de cada período mensal. O gerente geral tornou o gerente de operações diretamente responsável por esse controle daquele ponto em diante.
O gerente de operações sugeriu que o estoque anual fosse coordenado com a transição para o novo software de contabilidade. Por sua vez, o gerente geral aceitou essa sugestão como uma solução pragmática.
O antigo e o novo sistema de contabilidade funcionaram paralelamente por alguns meses e, no ponto de transição, o gerente de operações trabalhou em estreita colaboração com o gerente de contabilidade para garantir que o “Livro” correspondesse às avaliações de estoque do “Sistema” e começou a operar sob o novo software de contabilidade.
Para a decepção do gerente geral, as variações entre as duas avaliações de estoque continuaram e o valor contábil aumentou. O gerente de operações foi submetido a um escrutínio severo e os auditores da equipe corporativa foram enviados ao centro de distribuição. Foram solicitados pedidos de documentação comprobatória do último inventário. Nesse ponto, o gerente de operações parou de aparecer para trabalhar e não estava retornando ligações.
Pouco depois, foi descoberto que uma quadrilha de roubo estava sendo conduzida pelo gerente de operações. As variações descritas foram devidas a estoque roubado no valor de vários milhões de dólares, ou cerca de 3 por cento dos ativos no balanço da subsidiária. A atividade fraudulenta foi encoberta por dois anos pela falta de SOD em três áreas:
- O gerente de operações tinha responsabilidade pelo estoque e acesso administrativo ao software de contabilidade. Isso deu a ele a capacidade de conectar o inventário no ponto de transição para o novo sistema.
- O processo de carregamento de dados do inventário físico para o novo aplicativo de software foi fortemente influenciado pelo gerente de operações e forneceu cobertura para ocultar a vasta diferença entre as contagens de livros e sistemas no ponto de transição.
- A segregação entre a revisão e aprovação do carregamento de dados e o envio final para a produção não foi conduzida corretamente. Foi um erro do gerente geral.
SOD na implementação de um novo software é onde esse problema se tornou excessivo; o problema de inventário foi varrido para debaixo do tapete durante o carregamento de dados!
Estudo de caso nº 2: Processos de vendas e gerenciamento de dados: um risco de reconhecimento de receita
Um representante de vendas muito experiente tecnicamente para uma empresa de publicidade construiu um modelo de receita de publicidade que só ele entendeu. A receita baseava-se na venda de acesso a uma grande base de clientes para anunciantes em potencial e, em seguida, na transmissão de mensagens publicitárias para esses clientes.
O representante de vendas iria vender as ofertas, escrever os pedidos de inserção para o conteúdo transmitido e relatar à contabilidade sobre as ofertas fechadas e entregues. Muitas vezes, esses negócios foram estruturados com um componente de troca.
Claramente, o representante de vendas tinha muito controle sobre muitos dos componentes do reconhecimento de receita - ele criou pedidos de inserção fraudulentos que faria com que seus parceiros comerciais assinassem para concluir a transação de troca.
No entanto, os parceiros comerciais nunca entregaram seus compromissos aos pedidos de inserção, e o representante de vendas foi o único que entendeu o sistema de transmissão de e-mail, incluindo como acessar os arquivos de log.
Essa atividade fraudulenta não foi detectada até que o parceiro comercial foi vendido para outra empresa. A nova gestão do parceiro comercial foi apresentada com pedidos de inserção que não tinham a documentação de suporte adequada. Por sua vez, a administração decidiu ligar para a empresa do representante de vendas para discutir o assunto.
Foi só nessa época que esse esquema de $ 900.000 dólares foi descoberto!
Qual é a lição? Cuidado com a segregação entre receita e operações técnicas.
Seja cauteloso e vigilante
Embora SOD pareça um processo simples, não segui-lo adequadamente pode levar a consequências desastrosas, evidenciadas pelos dois estudos de caso acima. Como CPAs, você tem o conhecimento para garantir que o SOD seja devidamente implementado em sua própria organização, bem como nos negócios de seus clientes.
Comentários
Postar um comentário