Como escrever uma política interna de uso do GUEPARDO Tax para a área fiscal?

Pelo lado da auditoria, política sem evidência não se sustenta. E aí, o plano é exigir três registros por mudança: o que mudou, quem pediu e quem validou.

Pela nota de projeto, extensões Z em volta do fiscal são a parte que mais quebra na atualização. Vale um inventário vivo com dono, objetivo e o que cada extensão assume do produto, mais análise de impacto antes e regressão depois. Como o produto registra o histórico de mudança de configuração, a documentação disponível não afirma; confirme com a NTT ou teste no ambiente.

Discordo de tratar tudo como política de TI. Veja, pelo meu histórico, o erro comum é esperar que a política resolva decisão tributária.

Segundo a nota de projeto, o produto não define estratégia tributária, não corrige dado mestre ruim e não substitui governança. Então o texto precisa dizer quem decide cada regra fiscal (o tributário do cliente) e deixar para a TI só a execução. O período de guarda da evidência também se define com o jurídico, não com a TI.

Aqui, bem, no nosso caso, fizemos em duas camadas em vez de um documento só: uma política curta de princípios e um procedimento por rotina (acesso, mudança, evidência). Dá para revisar o procedimento sem reabrir a política. O custo é ter mais um documento para manter, então só compensa se cada um tiver dono.

Sobre consultor externo, a nota de projeto fala em acesso individual, nunca por credencial compartilhada, revogado ao fim do trabalho. Isso virou regra escrita no nosso procedimento.

Comece por três perguntas, não por um modelo: quem pode apurar, quem pode aprovar e quem lança a guia.

A nota de projeto que li diz que perfil de acesso costuma ser tratado como assunto de TI e ninguém confere se a mesma pessoa faz as três coisas (confiança baixa, amostra pequena). O detalhe é que, ó, essa conferência cabe numa tabela de uma página com pessoa, função e o que ela pode fazer. Na primeira revisão, cruze a tabela com a lista real de usuários do ambiente.