Uma obrigação que existe no papel mas não tem um proprietário não existe para um auditor. É nisto que muitas organizações encravam. Foi identificada uma obrigação de reporte, foi redigida uma política, mas a pergunta sobre quem cuida diariamente de que a política seja executada e quem pode demonstrar que isso acontece permanece sem resposta. Sem um nome associado a uma obrigação não há controlo, e sem controlo não há compliance demonstrável.
A titularidade de uma obrigação é mais do que um nome num organograma. Significa que uma pessoa ou uma função é responsável por três coisas: que a obrigação seja executada, que a prova disso seja registada, e que essa prova seja encontrável no momento em que alguém a solicita. Um proprietário que apenas sabe que uma tarefa lhe pertence, mas não consegue mostrar o que ficou registado a esse respeito, é na prática não um proprietário, mas um nome numa lista.
Esta distinção é exatamente onde muitos sistemas de controlo interno ficam a dever. A política é definida a nível da administração, a execução ocorre a nível departamental, e a ligação entre ambas raramente é tornada explícita. Como essa ligação pode ser feita, e por que a política e a prática se distanciam sem essa ligação, está descrito em como demonstrar que a política também é prática.
Numa organização singular, o proprietário de uma obrigação costuma ainda ser identificável: há uma entidade jurídica, uma administração, um conjunto de contas. Num grupo com múltiplas entidades, isso muda. Uma obrigação que se aplica a nível de grupo tem de ser executada em algum lugar da organização, e isso pode acontecer a nível do grupo, a nível de uma empresa operacional, ou distribuído por várias entidades que fornecem cada uma parte da informação.
A pergunta sobre quem é o proprietário torna-se então uma pergunta sobre estrutura: qual entidade consolida os dados, qual entidade fornece os dados subjacentes, e quem é responsável quando um desses elos falta. Esta questão surge de forma tão frequente e específica em estruturas de grupo que existe um tratamento próprio para ela: quem é o proprietário de uma obrigação num grupo com múltiplas entidades aborda como essa responsabilidade se divide e onde a divisão falha.
Titularidade e prova estão ligadas, mas na prática afastam-se. Um proprietário é designado com base num organograma, enquanto a prova de execução é registada noutro sítio: num e-mail, numa folha de cálculo num disco local, num sistema usado apenas numa empresa operacional. Quem tem de prestar contas a nível de grupo precisa então primeiro de descobrir onde está a prova antes de poder demonstrar que a obrigação foi cumprida.
Este problema não é incidental, é estrutural em qualquer organização composta por várias partes. É precisamente aqui que onde a prova se dispersa num grupo com múltiplas entidades avança: quais os pontos numa organização onde surge prova sem que alguém a recolha centralmente, e por que isso só se nota no momento em que um auditor a solicita.
Nem todo o documento apresentado conta como prova para um auditor. Um documento de política demonstra que existe uma intenção, não que essa intenção foi executada. Uma ata de reunião do conselho demonstra que um assunto foi discutido, não que uma decisão foi seguida. A prova tem de ter uma ligação direta à obrigação que deve fundamentar: quem fez o quê, quando, e como foi registado.
Num grupo com múltiplas entidades, esta questão torna-se mais complexa, porque a prova pode surgir a diferentes níveis e nem todos os níveis têm o mesmo valor probatório. O que nessa situação especificamente conta como prova, e por que a prova de uma entidade não é, sem mais, prova para a obrigação do grupo, está desenvolvido em o que conta como prova numa obrigação num grupo com múltiplas entidades.
Uma lista de proprietários é um ponto de partida, não um sistema. Para estar demonstravelmente em control, cada obrigação tem de estar ligada a um proprietário, à prova que esse proprietário produz, e a um control que verifica se essa prova está completa e atualizada. Essa ligação é frequentemente registada numa control matrix, um panorama que mostra por obrigação quem é responsável e como isso é controlado. O que exatamente uma control matrix implica, e por que uma lista de proprietários sem essa matriz não resiste a uma auditoria, é tratado em o que é uma control matrix.
Igualmente importante é a questão de onde essa prova é guardada, e se um auditor a consegue localizar sem ajuda da organização. Um sistema que depende do conhecimento de um único colaborador não é um sistema, é um risco. Como a prova é guardada de forma a permanecer encontrável, mesmo quando um grupo é composto por múltiplas entidades, está descrito em como guardar a prova de modo a que um auditor a encontre num grupo com múltiplas entidades.
Atribuir titularidade e organizar a documentação de prova é trabalho: elaborar panoramas, reunir documentação, acompanhar quem entregou o quê. Parte desse trabalho é repetível e segue um padrão fixo, o que o torna adequado para apoio por IA. O werkscan da FTE TO AI calcula, por tarefa, que parte desse trabalho pode ser assumida, tornando visível onde as pessoas continuam a ser necessárias para avaliação e onde os sistemas podem assumir a recolha e organização da prova.
Vraag maar welke verplichting op u van toepassing is, en waaraan u dat kunt aantonen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.