Você tem dúvidas sobre para que serve uma Matriz de Riscos, ou em que momento utiliza-la? Nesta serie de artigos sobre o tema Matriz de Segregação de Função (Riscos SoD) você ira tirar muitas das suas dúvidas.
A Segregação de Função, (que vem do termo em inglês de “Segregation of Duties” (SoD) ou “Separation of Duties”) é o conceito de ter mais de uma pessoa sendo necessária para completar um conjunto de tarefas consideradas críticas. Nos negócios, a segregação por meio do compartilhamento de mais de um indivíduo em uma única tarefa, é um controle interno destinado a evitar fraudes e erros. O conceito é alternativamente chamado de segregação de função ou, no campo político, segregação de poderes. – fonte Wikipedia.
A estrutura técnica de matriz de riscos abaixo ilustra os principais atributos necessários para definição de um risco de Segregação de Função (SoD) e/ou de Sensitive Access Transaction (SAT) e portanto a composição do conjunto de regras denominado Matriz de Riscos. Essa estrutura faz parte do método TrustSis para definição, criação, ajustes de matriz de riscos SoDs/SAT e controles compensatórios.
Figura: Estrutura da Matriz de Riscos SoDs
Para que serve a matriz de riscos e devo utilizar as já existentes no mercado?
É muito comum empresas preocupadas em evitar fraudes, erros ou até mesmo pelo simples desejo de conhecer melhor seus processos, possuírem uma matriz de Riscos com várias regras de Segregação de Função (SoD) para identificar quais indivíduos podem realizar tarefas consideradas críticas e conflitantes. Caso essas tarefas estejam segregadas em diferentes indivíduos, nenhuma regra SoD será violada e, portanto, não haverá riscos de ocorrerem fraudes ou erros.
Uma analise de riscos SoD busca identificar e apontar os usuários de um sistema que está sendo monitorado, que possam estar violando regras de riscos SoDs. Vamos utilizar como exemplo a regra de risco SoD que busca identificar usuários – num sistema monitorado – que possam realizar compras e ao mesmo tempo também possuam acessos para realizar pagamentos destas compras. Para este cenário o usuário do exemplo estaria violando uma regra de risco SoD e portanto seria apontado no relatório resultado da análise. Com base neste resultado da análise, apontando violação da regra, inicia-se o processo de reconhecimento da legitimidade da violação apontada, avaliando conforme os seguinte critérios:
A regra de risco violada aponta usuário com poder para comprar e realizar pagamento, no entanto por definição de negócio da organização esse risco é legitimo e aceitável pela área, gerencia, controles, auditoria etc.. Neste caso aplica-se um controle compensatório.
A regra de risco violada aponta usuário com poder para comprar e realizar pagamento, no entanto por definição de negócio da organização esse risco não é aceitável pela área, gerencia, controles, auditoria etc.. Neste caso aplica-se as etapas de remediação.
-
- Determinar se a regra de risco SoD de fato representa o conjunto de privilégios conflitantes corretos para identificar as violações de riscos SoDs e, portanto, as não conformidades. Ajustar as regras – se for o caso – e realizar nova analise de riscos SoDs;
- Determinar se os privilégios do perfil do usuário podem ser corrigidos para eliminar a violação da regra de riscos SoD. Neste cenário deve-se observar se os perfis de acesso do usuário são compartilhados com outros usuários, para determinar se os ajustes não trarão impactos a estes, que possam ter a necessidade de manter os privilégios ora sendo modificados,
- Avaliar se as tarefas e/ou transações e /ou ações não estejam permitindo a execução de atividade conflitante (ex. comprar e pagar) intrinsecamente por definição do fornecedor do sistema. Essa situação é mais difícil de mapear, porém, alguns fornecedores (ex. SAP) possuem notas informativas detalhando essas “anomalias”.
Dependendo do resultado da analise de riscos SoDs, recomenda-se um projeto de redesenho de perfis de acesso e/ou avaliação e ajustes do processo de gestão de acesso e monitoramento de riscos SoDs. Quando o resultado da análise aponta que a maior parte dos usuários do sistema avaliado violada riscos SoDs, geralmente isso implica – na grande maioria dos casos – que o modelo de perfis de acesso (e ate o processo gestão de acesso e monitoramento de riscos SoDs) deveria ser revisto e melhorado, para ase obter maior efetividade do controle desejado.
Matrizes de Riscos SoDs oferecidas por empresas de consultorias ou ferramentas de GRC podem ser utilizadas por minha empresa?
A resposta para esta dúvida é SIM e NÃO. E tudo dependerá da avaliação dos critérios abaixo, usados para tomada de decisão.
Toda matriz de Riscos SoDs “out-of-box”, aquelas oferecidas por empresas de consultorias ou ferramentas de GRC (ex. SAP GRC Access Control) trazem um conjunto de regras que representa a combinação crítica de tarefas e/ou transações e /ou ações de um dado sistema de negócio (por exemplo: SAP ECC, S4/HANA, Oracle, Ariba, TOTVS Protheus, TASY, RM, HCM , CRM, SRM, RH, Success Factor etc.). Estas combinações são baseadas em processos e/ou módulos ativos dos sistemas do negócio em questão. Sendo assim, a matriz será totalmente aderente ou não, caso os ERPs (do nosso exemplo) tenham as mesmas tarefas e/ou transações e /ou ações sendo utilizadas.
Como determinar se a Matriz de Riscos é aderente 100% para minha empresa?
A maneira mais simples de avaliar se as matrizes de riscos SoDs “out-fo-box” oferecidas por empresas de consultorias ou ferramentas de GRC (ex. SAP GRC Access Control) tem aderência ao sistema de negocio da sua empresa, é considerando e buscando as repostas para as seguintes questões: A Matriz de Risco Sod,
-
- Possui as tarefas e/ou transações e /ou ações equivalentes a versão de release do meu sistema de negócio?
- Representa todos os processos e módulos ativos do meu sistema de negócio?
- Apresenta processos e módulos que não fazem sentido ao meu sistema de negócio?
- As customizações realizadas pela minha empresa deveriam ser contempladas nesta matriz de Riscos “out-of-box”?
- As combinações de riscos SoDs representam as particularidades do meu negócio para evitar falsos positivos nos resultados das analises de riscos?
Exemplo: fluxo de aprovações onde é obrigatório que qualquer pagamento seja submetido sistemicamente para aprovação e liberação.
-
- A descrição dos riscos possui um linguajar que os usuários da minha organização possam entender?
- A criticidade dos riscos da matriz estão alinhados com a criticidade desejada pela nossa organização?
- Todos os riscos da matriz foram reconhecidos pela nossa organização como sendo legítimos?
Essas entre outras questões são de extrema importância para determinar se a Matriz de Riscos SoDs oferecida por empresas de consultorias ou ferramentas de GRC (ex. SAP GRC Access Control) é aderente ao seu sistema de negócio e pode ser utilizada sem passar por um processo de revisão e adequação.
Vale lembrar que na intenção de possuir uma Matriz de Riscos SoD a qualquer custo para resolver um GAP de auditoria, realizar um redesenho de perfis de acesso ou até tentar estabelecer um processo de gestão de acesso e monitoramento de riscos SoD, pode – consequentemente – gerar um ciclo de outros problemas quando não observados as questões apontadas acima. É recomendado entender a estrutura da Matriz de Risco SoD adquirida e para não estabelecer um roadmap de melhorias que possa piorar o cenário de riscos da sua organização é importante consultar um parceiro de serviços com experiência para propor as melhores práticas de ajustes, adequação e processo de uso da matriz de riscos SoD.
Entre em contato conosco e tenha profissionais altamente capacitados para lhe ajudar nesta escolha!
