csrdcompliance Colocar-me na lista de espera

Kennisbank

Quem deve ser o proprietário de uma obrigação

Uma obrigação sem proprietário não é uma obrigação, é um risco que ainda ninguém detetou. Ainda assim, esta é a questão em que muitos dossiês encravam: não quais regras se aplicam, mas quem dentro da organização é responsável por demonstrar que algo é feito com isso. Esta é uma das questões centrais que a Compliance Check responde por obrigação, juntamente com a questão de que prova é necessária e que control lhe está associado.

Por que a titularidade não surge por si só

Na prática, uma obrigação é frequentemente atribuída com base em quem primeiro se depara com ela. O jurista que lê o artigo torna-se o proprietário. O controller que compila o relatório torna-se o proprietário. Isso funciona até ao momento em que é preciso prestar contas, e se revela que ninguém tem uma visão geral do que exatamente foi prometido e com base em que prova.

Uma titularidade que surge por acaso não é uma titularidade que uma administração possa explicar. A questão que a Compliance Check coloca não é, portanto, quem atualmente se ocupa disso, mas quem tem a competência, a visão geral e a responsabilidade para assumir a obrigação, incluindo a prova correspondente.

Três características de um proprietário

Um proprietário de uma obrigação não é, por definição, quem executa o trabalho. Há três características que, em conjunto, determinam se a titularidade está no lugar certo.

Primeiro: o proprietário consegue explicar a obrigação sem recorrer a uma parte externa. Se apenas um consultor consegue reconstruir por que uma determinada regra se aplica ou não, a titularidade está, de facto, fora da organização.

Segundo: o proprietário tem acesso à prova, ou a competência para a solicitar. Um proprietário que não sabe onde está a documentação subjacente é proprietário no nome, não na prática.

Terceiro: o proprietário é quem é interpelado quando o control não funciona. É frequentemente aqui que as coisas correm mal: o nome no overview não é a mesma pessoa que presta contas quando algo é testado.

O que o método não resolve aqui

A Compliance Check não designa um proprietário. Um instrumento não pode fazer isso, e também não deveria. Quem, dentro de uma organização, tem a competência e a capacidade para assumir uma obrigação é uma questão organizacional, não jurídica ou técnica. O método regista qual obrigação necessita de titularidade, que prova lhe corresponde e que control demonstra que funciona. Quem desempenha esse papel continua a ser uma decisão da própria organização.

É também aqui que o método tem limites que vale a pena mencionar. A Compliance Check não trata da questão de se um funcionário tem senioridade suficiente, nem da questão de se uma equipa tem capacidade suficiente para desempenhar o papel. Essas questões estão fora do alcance de um overview que liga obrigações a prova e control.

A titularidade varia por país

Uma complicação adicional é que a titularidade não é preenchida da mesma forma em todos os lugares. Uma regra europeia pode, num país, estar sob a função financeira e, noutro país, sob os assuntos jurídicos, simplesmente porque a implementação nacional coloca aí um enfoque diferente. Este é um dos pontos em que os cabeçalhos nacionais são estruturalmente subestimados: como acompanhar isso por país sem cair numa jungle de subscrições é uma questão que se resolve de forma diferente por organização, dependendo de quantas jurisdições são relevantes.

Por que isto é mais do que preencher um nome

A diferença entre um relatório e um overview funcional está precisamente aqui. Um relatório enumera obrigações. Um overview útil para uma administração associa a cada obrigação um proprietário, uma forma de prova e um control, e torna visível onde esses três não se alinham. Por que isso exige uma abordagem diferente da de entregar um relatório é desenvolvido mais na página sobre por que uma compliance check é algo diferente de um relatório.

A questão de quem deve ser o proprietário está, além disso, ligada ao que exatamente é pedido quando um terceiro testa o dossiê. Uma declaração de assurance não pede apenas um nome associado a uma obrigação, mas um rasto que mostre que esse nome também conseguia efetivamente verificar se o control funcionava. O que uma declaração de assurance exige de um dossiê está descrito na página o que uma declaração de assurance exige do seu dossiê.

E, por fim: a titularidade que não existe tem um custo, mesmo que ainda não se tenha manifestado. O que custa não saber a que categoria uma organização pertence, e, portanto, também não saber quem deveria ser responsável por quê, é tratado na página o que custa não saber a que categoria pertence.

A ferramenta está em construção

A Compliance Check existe agora como método: uma forma de associar obrigações a proprietário, prova e control. A ferramenta que faz isto de forma automática e contínua ainda está em desenvolvimento. Quem já quiser trabalhar com isto pode inscrever-se na lista de espera; não é oferecido nada que ainda não exista.

A próxima questão que surge

Uma vez claro quem deve ser o proprietário de uma obrigação, surge naturalmente a questão de quanto tempo esse proprietário gasta com isso, e que parte desse trabalho é suficientemente repetível para ser organizada de outra forma. A FTE TO AI oferece para isso um werkscan que calcula, por tarefa, que parte do trabalho pode ser assumida por IA, de modo que a titularidade não signifique automaticamente que alguém continue a reunir manualmente prova para obrigações que já podem ser bem estruturadas.

Alpha 60de assistent van de Compliance Check

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.