Menu principal

Controles de TI para Sarbanes-Oxley

Página para Impressão Indique a um Amigo

Com o advento da Lei Sarbanes-Oxley que determina a criação de um conjunto de procedimentos internos de mecanismos de auditoria e segurança confiáveis nas empresas a área de TI se deparou com a oportunidade de construir um modelo de governança considerand

Introdução

Com o advento da Lei Sarbanes-Oxley que determina a criação de um conjunto de procedimentos internos de mecanismos de auditoria e segurança confiáveis nas empresas a área de TI se deparou com a oportunidade de construir um modelo de governança considerando aspectos de responsabilidade de prestação de contas e desta forma responder rapidamente aos requerimentos do negócio. Tendo como objetivo a construção de ambiente de controle interno robusto as empresas se permitirão alcanças maiores ganhos na vantagem competitiva através de operações mais eficientes, com abordagem integrada em segurança, integridade e disponibilidade, aumento na competência de gerenciamento de riscos e priorização das iniciativas.

Alcançarão melhor entendimento dos requerimentos do negócio e forte alinhamento entres os executivos e finalmente contribuirão para aumentar a conformidade em relação às demandas legais e do mercado.

A lei Sarbanes-Oxley impôs à United States Securities and Exchange Commission (SEC, 1934) a obrigação de criar uma regulamentação para coibir práticas ilícitas dentro das organizações na elaboração dos relatórios financeiros. A SEC criou o Public Company Accounting Overnight Board (PCAOB, 2002), órgão encarregado de fiscalizar as companhias abertas e as empresas de auditoria, e este recomendou a adoção da estrutura de controles internos definidos e apresentados pelo Committee of Sponsoring Organizations of the Treadway Commission (COSO, 1985). Entretanto, o COSO elaborou uma definição comum de controles internos voltados para a transparência na elaboração dos controles internos, não sendo muito detalhado e objetivo para aplicação de controles na área de TI. Para cobrir esta lacuna os auditores buscaram no Control Objectives for Information and related Technology (COBIT, 1992) a estrutura de controle mais adequada para estabelecer objetivos de controle para a área de TI.

O COBIT provê uma abordagem genérica sobe como devem ser definidos os processos de TI e desta forma cada organização deve considerar cuidadosamente quais serão os controles mais apropriados ao tamanho e a complexidade da empresa.

Elaboração de relatórios financeiros confiáveis.

A área de TI tem papel fundamental hoje em dia para a elaboração dos relatórios de demonstrações financeiras. Seja um sistema completo de ERP ou sistemas menos complexos. Em qualquer caso entendemos que temos todos os processos de uma empresa relacionados com as operações que alimentam as transações financeiras.

No entendimento de como os controles de TI coexistem dentro de uma empresa podemos dividi-la em três elementos: a) Gerenciamento Estratégico; b) Processos de negócios; e c) Serviços de TI.

No Gerenciamento estratégico a alta direção da empresa estabelece e introduz a estratégia e boas práticas para os negócios possibilitando que os processos de negócios sejam utilizados como mecanismos para criação e entrega de valor para as empresas, acionistas e todas as partes interessadas. Estes processos passaram nas últimas décadas por uma crescente automação com a utilização integrada e complexa de sistemas de informação com base em TI.

Com este cenário a área de TI, juntamente com a lista de serviços que ele presta, se tornou uma área importante para a viabilização dos negócios, independentemente do tamanho da empresa, geografia ou ainda se os serviços são mantidos dentro da organização ou são terceirizados.

Neste contexto, em que os relatórios financeiros têm sua origem em dados e informações mantidos pela TI, podemos dizer que os controles dos processos de TI devem prover um ambiente de operação confiável para suportar uma efetiva operação nos controles da aplicação. TI é a base para propiciar um efetivo controle sobre os relatórios financeiros.
Etapas para a elaboração de um plano de Implementação

A primeira etapa para a efetiva implementação é a criação de comitês específicos que deverão definir, com base na legislação e nas estruturas de controle COSO e COBIT recomendadas. O Comitê principal deverá ser dirigido por um representante da área financeira, uma vez que o objetivo principal é a transparência e a fidelidade dos relatórios financeiros. Este comitê deverá ter um representante de TI que será responsável pela conexão com a área de TI e será o principal líder no comitê que deverá ser criado internamente em TI.

Este último será responsável por todas as iniciativas que serão definidas e implementadas em TI. Dentro do cenário de conformidade em que TI deve se enquadrar devem ser observadas as seguintes sub-etapas:
• Entendimento dos controles internos da organização e suas implicações nos relatórios financeiros
• Definição de quais aplicações influenciam nas demonstrações financeiras elaborando um mapa das aplicações inseridas no contexto com os respectivos donos destas aplicações
• Mapeamento dos processos e serviços de TI que apóiam os processos de negócio que são fundamentais para a elaboração dos relatórios financeiros
• Identificar os riscos relacionados com os processos mapeados
• Definir e implementar controles objetivando mitigar os riscos identificados
• Monitorar a execução dos controles de TI promovendo efetividade contínua
• Documentar e testar controles com base em sistemas ou processos manuais
• Assegurar que os controles de TI sejam atualizados e modificados quando necessários para corresponder as mudanças nos controles internos que apóiam relatórios financeiros

As regulamentações impostas pela SEC são inegavelmente complexas e suas implementações são custosas e demoradas. A adoção de outras técnicas como as relacionadas com gerenciamento de projetos são importantes para atingir prazos e orçamentos planejados.

Considerando esta elaboração do plano dentro de TI devemos observar quatro importantes pontos a serem avaliadas.

Escopo de implementação

É extremamente importante que sejam bem definidos quais os processos e objetos de TI que se enquadrarão dentro do conceito de que somente deverão ser inseridos no escopo aqueles sistemas e recursos que realmente contribuem para a elaboração das demonstrações financeiras. A inclusão de itens que não necessariamente estejam diretamente relacionados com o assunto certamente acarretará no aumento do prazo e custo do projeto.

Uma solução para acertar nesta definição seria a adoção de orientação de cima para baixo, com plena participação das áreas financeiras e TI considerando o mapa de aplicações como fonte para identificar os processos e recursos que as apóiam.

Comunicação

Um projeto deste porte e com reconhecida importância não pode ser entendido pela organização sem uma comunicação eficiente e abrangente que estimule a participação de todos os envolvidos. A clara definição de papéis e responsabilidades é fundamental para a clareza dos objetivos e a motivação dos envolvidos.

Capacitação
As pessoas que estarão diretamente ou indiretamente envolvidas no processo de adoção dos controles deverão estar preparadas e alinhadas com os objetivos do projeto. Treinamentos introdutórios e conceituais assim como aqueles específicos ligados aos modelos, estruturas de controle e boas práticas escolhidos como ferramentas devem ser fornecidos aos membros dos times.

Os custos relacionados à capacitação das equipes são consideravelmente menores aos relacionados com a implementação total do pacote de conformidade.

Avaliação do ambiente atual
O sucesso no gerenciamento de mudanças começa com uma verdadeira avaliação do estado atual das coisas. Fatores tais como: a) cultura, que envolve atitudes, história, flexibilidade, valores, língua, e outras variáveis são importantes para avaliar se a organização vai reagir rápido ou não; b) tamanho da mudança, que define quão significante será o esforço da organização em termos de recursos; c) impacto nas pessoas, avaliando se as elas responderão de maneira positiva ou negativa ao processo de mudança. Identificar os agentes de mudança é fundamental para o sucesso.

Plano de conformidade com a lei Sarbanes-Oxley
Um plano de conformidade para atender as demandas da lei Sarbanes-Oxley em TI deve passar por iniciativas que direcionarão a área de TI e seus profissionais a atingirem alto grau de conformidade. São elas:

Planejamento de definição do escopo dos controles de TI
É de extrema importância a identificação das aplicações e seus sistemas e sub-sistemas relacionados. Devem ser avaliados somente aqueles diretamente ligados com as demonstrações financeiras excluindo-se todos aqueles que muito remotamente tenham alguma relação. O resultado da avaliação está relacionado diretamente com a avaliação do risco financeiro envolvido e determinado pelo pessoal da área financeira.

Entre as iniciativas a serem consideradas sob este título destaca-se o seguinte:
• Atribuição de responsabilidades e prestação de contas nas posições de liderança do projeto
• Inventário das aplicações relevantes para as demonstrações financeiras e seus sub-sistemas correlatos
• Revisar a documentação dos processos financeiros e identificar os controles aplicáveis às aplicações
• Desenvolver um esboço do plano do projeto e obter aprovação
• Determinar as responsabilidades pelos controles das aplicações
• Considerar as dificuldades relacionadas com a geografia
• Considerar se alguma aplicação pode ser excluída do escopo
• Identificar dependências relacionadas com serviços de terceiros

O inventário de aplicações e seus sub-sistemas correlatos deve ser usado para o planejamento preliminar e em fase posterior ajudará a avaliar os riscos associados aos mesmos para determinar a natureza e a extensão dos controles e testes requeridos.

Uma clara definição dos papeis e responsabilidades eliminarão o trabalho redundante e ajudará TI a identificar os responsáveis das áreas de negócio necessários e os lideres do projeto para o bom andamento do mesmo. Algumas vezes o envolvimento da TI é tão particular que ela tem dificuldade de fazer esta identificação. A responsabilidade de TI é de assistir os donos do processo na identificação e testes dos controles enquanto asseguram que os estes estejam implementados e confiáveis.

Integrar a documentação dos processos de controle financeiro aos controles de TI envoltos por um esboço do plano aprovado, que considera aspectos geográficos e de relacionamento com terceiros é fundamental para o sucesso do projeto.

Avaliar Riscos em TI

Este requisito ajuda a avaliar os riscos que cada aplicação tem em relação a contribuição que cada aplicação e suas camadas de controle tem em relação a elaboração das demonstrações financeiras. Uma das mais significantes lições aprendidas no inicio da adoção da lei Sarbanes-Oxley foi que o projeto deve definir as aplicações que devem ser incluídas no escopo devem ser baseadas na razão direta do risco que a aplicação está exposta. Nem todos os sistemas e aplicações impõem altos riscos às demonstrações financeiras e desta maneira não precisam ser avaliados todos da mesma maneira.

Dois fatores devem ser analisados sob esta iniciativa:
• Avaliar o risco inerente das aplicações e sub-sistemas correlatos considerando a necessidade de determinar a natureza e a extensão dos controles para a mitigação do mesmo.
• Revisar o escopo em função dos riscos identificados e atualizar o plano de implementação
Identificar e documentar os controles

A identificação e documentação dos controles esclarecem para TI como os riscos estão associados à confiabilidade das demonstrações financeiras e como eles foram endereçados. Isto permite que TI tome decisões mais acertadas aceitando e comunicando os níveis remanescente de riscos.

Observando o que o PCAOB definiu como controles internos e adaptando o conceito a esta atividade de identificação dos controles de TI podemos acrescentar que um controle concernente à manutenção dos registros deve ter um detalhe razoável, acuracidade e correção no modo de refletir as transações intrínsecas ao controle.

Esta é uma das etapas mais importantes, pois é aqui que serão definidos os atributos que deverão compor a documentação base de trabalho e aonde identificados e categorizados todos os controles de TI.
Primeiro deverão ser definidos objetivos de controle que por sua vez deverão ser subdivididos em atividades de controle para facilitar o entendimento e possibilitar subdivisão de tarefas quando a complexidade exigir.

Na verdade devemos entender os objetivos de controle como uma declaração que comprove com uma razoável garantia de que o que está descrito no controle seja executado para assegurar a conformidade. As atividades de controle, associadas ao objetivo de controle, por sua vez, identificam os passos intermediários que devem ser executados com os responsáveis e demais características.

A seguir, alguns dos atributos que uma matriz de avaliação de controles internos baseados na lei Sarbanes-Oxley deve conter.
Ciclos de controle: Devem ser encarados como uma divisão de alto nível das principais áreas de atuação de TI. Podem variar de empresa para empresa, porém devem ser completos em sua aplicabilidade para abranger todos os pontos que são relevantes para as demonstrações financeiras. Como exemplo de um ciclo nós podemos usar o processo de gerenciamento de mudanças.

Objetivo de controle: Deve descrever o que se deseja atingir em termos de conformidade e o texto deve ser claro evitando ambigüidades. Continuando a usar o exemplo acima, dentro do gerenciamento de mudanças podemos ter como objetivos de controle: 1) as requisições de mudança de e manutenção de programas e sistemas são padronizadas, documentadas, registradas, aprovadas e armazenadas com todas as suas evidencias; 2) Mudanças emergenciais são documentadas e submetidas a uma aprovação formal dentro dos procedimentos vigentes para uma emergência: 3) os controles implementados garantem que uma mudança não autorizada não seja enviada para o ambiente de produção.

Atividade de controle: Considerando o objetivo de controle a que esta atividade está associada ela descreve procedimentos intermediários que em conjunto com as demais atividades asseguram a conformidade do objetivo de controle. Considerando o objetivo de controle numero 1 acima devemos descrever as etapas e os responsáveis. Como exemplo nós podemos definir: 1.1) existe uma comunicação formal sobre o processo de gerenciamento de mudança e as requisições estão disponíveis para acesso de todas as partes interessadas; 1.2) as requisições são armazenadas e processadas de forma que seja possível um acompanhamento de todo o processo de mudança desde seu inicio até sua finalização; 1.3) as aprovações são baseadas em uma tabela de decisão envolvendo o proprietário da aplicação e o especialista de TI responsável pela aplicação; etc.

Estes três atributos devem ser usados de forma hierárquica sendo que um clico possui diversos objetivos de controle que por sua vez possui várias atividades de controle.

Tipo de controle: Este atributo define se o controle é Preventivo ou Investigativo. Preventivo na medida em que previne a ocorrência de erros e fraudes com impacto nas demonstrações financeiras. Detectável por ser executado somente depois da ocorrência. A combinação destes dois tipos pode fornecer a empresa uma forte barreira contra fraudes.

Responsável: Identifica o funcionário que tem sob sua guarda os documentos, ferramentas e procedimentos que asseguram a execução daquele controle. Pode ser de qualquer nível hierárquico. Entretanto a hierarquia a que ele está subordinado também tem responsabilidades e tem seu envolvimento no processo de aprovação. Aqui precisamos ressaltar que a capacitação dos funcionários é uma responsabilidade inerente a estrutura de gerenciamento da empresa.
Natureza do controle: Pode ser manual ou automática. E certo que quanto mais automatizado for um controle melhor sua contribuição para a conformidade. Podemos ter como exemplo um processo de workflow de aprovação das mudanças. Entretanto ainda dependemos de controles manuais que complementem o conjunto de controles. Alguns deles nunca vão deixar de existir como, por exemplo, as inspeções físicas de inventário.

Risco: Uma avaliação de riscos deve ser feita para cada controle ou grupos de controle para permitir maior flexibilidade na execução dos mesmos. Podem ser usados critérios que vinculem os riscos de impacto nas demonstrações financeiras versus periodicidade d execução dos controles, permitindo uma melhor produtividade na execução e avaliação do controle.

Periodicidade: Cada controle tem uma característica em relação ao período de execução. Eles podem ser executados várias vezes num dia, diariamente, semanalmente, mensalmente ou anualmente. A correta identificação permitirá uma correta avaliação do tempo e utilização de recursos bem como facilitará o trabalho de auditoria que poderá definir os tamanhos das amostras para coleta de evidências.

Importância do controle: Controles que são relativamente mais importantes que os demais devem ser identificados para serem executados com mais atenção, pois serão os mais procurados pela auditoria. Por exemplo, controles relacionados com segregação de autoridade que podem provocar conflitos de interesse são controles importantes.

Prioridade: Com valores atribuídos de 1 a 3 identifica os controles que deverão ser auditados a cada 1 ano, a cada 2 anos e a cada 3 anos. Certamente este atributo deve ser definido em conjunto com a auditoria e tem como objetivo colocar foco naquilo que é mais importante. Com base em uma análise cruzada entre o risco, a periodicidade, a importância e a forma de execução pode-se obter muita produtividade na hora das avaliações.

Abrangência: Pode ser Interna ou Externa. Na medida em que as organizações se utilizam de serviços de terceiros é importante identificar se o controle está sob a responsabilidade direta de TI ou é amparado por um contrato, que neste caso deverá ter cláusulas bem claras de SLA.

Após a divulgação e o entendimento de como estes atributos devem ser preenchidos os seguintes passos devem ser seguidos.
Identificar controles de TI relacionados com sua entidade

Aqui serão definidos controles relacionados com o estilo de operação e organização da TI incluindo políticas, procedimentos e outras práticas de alto nível que indiquem os melhores aspectos de gestão da área.
Identificar Controles de aplicação

A identificação de controles de aplicação que apóiam relatórios financeiros é um passo crítico no processo. Uma vez que todos os controles de aplicação forem determinados seus respectivos controles gerais de TI podem ser determinados.

Geralmente, controles de aplicação estão inseridos na documentação dos processos financeiros. Idealmente o especialista em TI juntamente com especialista no processo financeiro identificam os controles relevantes a serem considerados par ao processo.

Devem ser considerados dois tipos de controle serem documentados:
• Controles automatizados. Totalmente dependentes de processos automatizados realizados por sistemas ou processos sem nenhuma interferência humana. Não estão sujeitos a erros intermitentes.
• Controles manuais com base em sistemas. São essencialmente controles manuais mas que dependem de inputs de alguns sistemas que apóiam estas atividades.

Identificar controles gerais de ti
A importância do relacionamento entre os controles da aplicação e ao controles gerais de TI recai na significância que os controles gerais de TI têm para apoiar a confiabilidade que os controles de aplicação têm que apresentar para permitir transparência às demonstrações financeiras. Exemplificando, garantir a segurança de um bando de dados, que é o repositório de dados financeiros, é considerado um requerimento básico para a confiabilidade dos relatórios financeiros.

Sem a esperada segurança as empresas estarão expostas a alterações não autorizadas nestes dados financeiros.

O desafio intrínseco aos controles gerais de TI está no fato de que eles raramente impactam os relatórios financeiros diretamente, entretanto eles tem um efeito distribuído e intenso por estarem presentes em praticamente todos os controles internos da organização. Isto é, se um controle geral de TI relevante falhar, como por exemplo, uma falha no controle de acesso a transações e dados financeiros, ele poderá provocar impacto nos dados e conseqüentemente afetar as demonstrações financeiras.

Identificar os controles relevantes
Riscos associados aos controles financeiros não são todos iguais em termos de probabilidade e materialidade. Similarmente controles financeiros não são os mesmos na sua efetividade em mitigar os riscos identificados. Além disso, não é requerimento da gerencia de TI a avaliação de todas as atividades de controle relacionadas como os riscos. Como resultado, as empresas devem se esforçar para limitar ao essencial a documentação dos controles relevantes.

Não existe resposta certa para quais controles são relevantes, portanto devemos ter em mente que controles relevantes são aqueles que mais assegurem aos donos destes controles o cumprimento efetivo dos objetivos de controle.

Considerar controles de TI anti-fraude
A importância de controles anti-fraude sob a lei Sarbanes-Oxley e algo que não pode ser deixado de lado. Fraude é a principal razão da introdução da lei, portanto atenção apropriada deve ser dada ao assunto.

Controle de acesso e segregação de responsabilidade são os dois mais importantes controles anti-fraude que a TI pode fornecer. A velha máxima, “quem faz não controla” tem uma importância significativamente alta nesta etapa.

Documentação dos controles
As companhias são obrigadas a documentar todos os controles e realizar avaliações de suas definições e a efetividade da operação. A documentação pode ter vários formatos como por exemplo: políticas da empresa, políticas de TI, organogramas e fluxogramas de processos, tabelas de decisão, etc.. A lei Sarbanes-Oxley não determina nenhuma peça de documentação em particular, deixando, portanto para as organizações a determinação de como deve ser esta documentação varia de acordo com o tamanho e a complexidade das empresas.

Avaliação dos controles e efetividade operacional

Um modelo de operação baseado em controles levou a TI a melhorar sua efetividade em termos de redução de risco e de conformidade com a legislação. Avaliar apropriadamente os atributos dos controles incluindo controles preventivos e investigativos na modalidade automática ou manual leva a determinação de níveis de maturidade e ajudam a organização a mapear a diferença entre o estado atual e o ideal do controle. Níveis de maturidade que vão de 0 a 5 ajudam a organização de TI a avaliar o estado atual dos controles. A legislação não demanda uma classificação dentro destes níveis, mas sua adoção permite uma melhor avaliação e indica o caminho a seguir no processo de melhoria contínua.

Os níveis são os seguintes:
• Estágio 0 – Não existente
• Estágio 1 – Inicial/Ad Hoc
• Estágio 2 – Repetitivo, porém intuitivo
• Estágio 3 – Processo Definido
• Estágio 4 – Medido e gerenciado
• Estágio 5 – Otimizado

Outras iniciativas dentro deste contexto estão ligadas à avaliação da efetividade operacional que passa pela determinação de como os controles devem ser testados depois de avaliada sua definição. Os controles devem ser avaliados quanto a natureza manual ou automática e os volumes das amostras para teste devem ser escolhidos de acordo com a freqüência em que estes controles são executados. Controles automáticos necessitam de amostras menores para sua validação.

Ainda neste contexto devemos considerar também a natureza da evidencia requerida observando critérios de investigação, com o objetivo de obter informações relevantes para aquele controle específico, além de procedimentos de inspeção de documentos para assegurar uma efetiva execução do controle. A observação pertinaz do ambiente a procura de pontos de controle que não foram identificadas até então também constitui iniciativa apropriada para melhorar o desempenho geral do plano de implementação.

Por último, mas não menos importante, é a consideração do momento em que a evidência é gerada ou coletada. Ele deve servir para documentar a execução de um referido controle dentro de um razoável balanceamento entre o custo que se tem para obtê-la e o retorno em termos de efetividade que a evidência prova.

Priorização e remediação das deficiências
Após avaliar os controles depois dos testes realizados podemos nos deparar com controles em não conformidades, de acordo com uma orientação recomendada pelo PCAOB em 2004, classificadas em:
• Deficiências em aplicações. Devem ser avaliadas em função da significância em relação ao impacto que elas causam no controle da aplicação.
• Deficiências no ambiente de controle. São geralmente associadas a uma ou mais deficiências que em conjunto podem provocar um efeito maior no ambiente e se tornar uma deficiência significativa.
• Falhas em remediar uma deficiência em um tempo razoável podem levar uma deficiência a ser interpretada como uma deficiência significativa ou ainda se considerada uma deficiência material dependendo de quanto tempo a falha está para ser sanada.

As deficiências ainda podem ser consideradas como deficiência de definição ou deficiência de efetividade operacional. A primeira está relacionada à maneira como o controle foi concebido. Se ele não é completo em sua efetividade para documentar e validar um processo ele dever ser revisto e modificado. A segunda refere-se a forma com que o controle é executado. Se ele não observar a freqüência determinada isto pode ser interpretado como uma deficiência operacional.

Construindo sustentabilidade
Neste momento TI deve estar em posição de avaliar a efetividade do programa de implementação de seus controles internos. Controles internos efetivos e avaliação e gerenciamento das competências internas devem se tornar parte integrante da organização e cultura de uma área der TI e manter a efetividade e a conformidade no longo prazo. Controle não é um simples evento, mas um processo que requer melhoria contínua para manutenção de um alto nível de eficiência.

Algumas iniciativas que contribuem para que TI seja reconhecida como estando nesta fase são:
• Revisões pós-implementações do projeto identificando o que deu certo e áreas de melhoria
• Acompanhamento das atualizações na legislação
• Incorporação de melhorias oriundas de outras fontes independentes
• Reuniões com pares de outras organizações
• Desenvolvimento de planos e agendas para os próximos anos
• Avaliação de ferramentas de automação para buscar soluções de continuidade para consolidar um processo de gerenciamento de controle no longo prazo

Outros quesitos, também relacionado com a sustentabilidade, são a racionalização e a automação dos controles. Ao longo do tempo os processos sofrem alterações, tanto dentro quanto fora de TI. Os controles de TI devem ser revisados periodicamente e adaptados às novas condições encontradas. A automação dos controles é indubitavelmente uma melhoria que não pode ser deixada de lado.

Aqueles controles que podem ser automatizados devem ser considerados para fazer parte de um esforço de automação. Com isto será construído uma base sólida para a sustentabilidade do programa de implementação de controles.


Notas:
Demonstrações financeiras e relatórios Financeiros são expressões usadas em diferentes parte do texto, porém com o mesmo significado na medida que procuram definir o objeto de foco na legislação para a transparência e autenticidade dos números.

Referência bibliográfica e outras fontes:
IT Control Objectives for Sarbanes-Oxley. The role of IT in the Design and Implementation of Internal Control Over Financial Reporting 2nd Edition. September 2006
Lei Sarbanes-Oxley de 23 de Janeiro de 2002
Auditing Standard No. 2 – An Audit of Internal Control Over Financial Reporting Performed in Conjunction with An Audit of Financial Statements. Public Company Accounting Oversight Board (PCAOB).
COBIT® 3rd Edition Audit Guidelines. July 2000.
Material de treinamento do curso de Controles de TI para SOX ministrado pela World Pass em Março de 2007.



1 2 3 4 5 6 7 8 9 10
Controles de TI para Sarbanes-Oxley
© Copyright 2010 Jose Luis Diniz & ISACA Chapter SP

Entrar

Calendário de Cursos e Eventos

SET 2010
DSTQQSS
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
(DF) ICCyber 2010
16
(DF) ICCyber 2010
17
(DF) ICCyber 2010
18
19
20
21
22
23
24
25
26
27
(SP) II Congresso sobre Crimes Eletrônicos e formas de proteção
28
(SP) II Congresso sobre Crimes Eletrônicos e formas de proteção
29
30
Agenda de Eventos Agenda de Eventos  
Fotos Fotos