Segurança e compliance em gestão de despesas corporativas: a diferença entre prática e bandeira

• Compliance como prática, não como bandeira
• Trilha de auditoria como coluna vertebral
• Segregação de função no desenho do sistema
• Controles preventivos e controles corretivos
• Controlador e operador na regulação de dados
• Certificação como sinal, não como bala de prata
• Compliance como resultado composto

Há duas maneiras de tratar segurança e compliance em software corporativo. Uma trata como prática de arquitetura, cultura interna e execução consistente ao longo do tempo. A outra trata como bandeira comercial exposta em toda apresentação, com selo de certificação em destaque no site e no material de vendas. As duas maneiras produzem resultados muito diferentes, e a diferença aparece exatamente quando algo dá errado, quando auditoria pede evidência, quando regulador chega para investigar.

Este artigo desenvolve o argumento a favor da primeira maneira, com cinco dimensões distintas do problema: trilha de auditoria como coluna vertebral do sistema, segregação de função no desenho, controles preventivos e controles corretivos, papéis distintos de controlador e operador em regulação de dados, e o papel da certificação como sinal técnico, não como bala de prata comercial. Cada dimensão contribui para o resultado composto que é compliance real.

Compliance como prática, não como bandeira

O discurso de mercado sobre compliance em software corporativo frequentemente confunde duas coisas distintas. A primeira é o conjunto de práticas técnicas, de processo e de cultura que produzem operação em conformidade com regulação, política interna e boas práticas do setor. A segunda é o conjunto de sinais externos (certificações, selos, declarações) que uma organização usa para comunicar que opera dessa forma.

A diferença entre os dois modos importa porque tem consequência prática. Organização que trata compliance como bandeira comercial tende a investir mais em obter certificação do que em construir prática que a certificação deveria refletir. O incentivo se organiza em torno do exame de certificação, e não em torno da operação cotidiana. O resultado é sistema que passa na auditoria formal e falha em auditoria adversarial ou em situação real de crise.

Organização que trata compliance como prática investe em arquitetura correta, em processos que funcionam sem depender de disciplina heroica de indivíduos, em cultura interna que valoriza rigor sem burocratizar tudo. A certificação, quando vem, é resultado natural desse investimento, não objetivo dele. E o sistema que emerge funciona não porque foi construído para passar em exame, mas porque foi construído para operar corretamente.

Software corporativo maduro segue a lógica de que as decisões técnicas de segurança e compliance são tomadas por argumento técnico, e não por conveniência comercial. A certificação vem, e é comunicada de forma sóbria, porque a certificação tem função legítima. Mas ela não substitui, nem representa, o trabalho real que sustenta a operação em conformidade.

Trilha de auditoria como coluna vertebral

Trilha de auditoria em software de gestão de despesas corporativas é o registro completo de cada evento significativo do sistema: quem, quando, o quê, e frequentemente contra o quê. É o mecanismo que permite reconstruir a história de qualquer transação, meses depois, com detalhe suficiente para responder às perguntas que auditoria, regulador ou investigação interna venham a formular.

Embora existam referências de mercado, implementações reais variam entre clientes e entre configurações. Algumas empresas implementam a referência completa, outras uma versão parcial, seja por razões técnicas, seja por escolha de política interna, seja por combinação das duas. Nenhuma implementação real é perfeita e reconhecer isso é parte de discutir o assunto com honestidade.

Uma trilha de referência captura pelo menos quatro tipos de evento por transação.

O primeiro é o cadastro. Quando uma despesa entra no sistema, é registrado quem cadastrou, quando cadastrou (data e hora precisa), com que dados iniciais, e a partir de qual canal (aplicativo móvel, portal web, integração com cartão, integração com sistema de viagem).

O segundo é a aprovação. Quando a despesa passa por aprovação, é registrado quem aprovou, quando, com que justificativa se exigida, contra qual limite de política, e se houve escalação para nível superior (e por qual razão). Em alguns clientes, a aprovação é única. Em outros, é dupla ou tripla, dependendo do valor e da categoria. A trilha reflete o regime que o cliente configurou.

O terceiro é o pagamento. Quando o pagamento é efetuado (via cartão corporativo já executado, via reembolso em conta, via PIX direto), é registrado quem processou a ordem de pagamento, quando, contra qual conta, e com qual referência bancária associada. Essa parte da trilha é frequentemente objeto de auditoria fiscal e de conciliação bancária.

O quarto é a conciliação. Quando o financeiro consolida a despesa nos registros contábeis, é registrado quem consolidou, quando, com que classificação contábil aplicada, com que ajuste (se houve), e com que integração enviada para o ERP do cliente. Essa parte da trilha é o que sustenta a rastreabilidade entre lançamento contábil e evento operacional que o originou.

A trilha completa permite reconstituir qualquer transação em detalhe. Quando o regulador pergunta como determinada despesa foi tratada, quando o auditor pergunta por que uma classificação foi aplicada, quando a investigação interna pergunta quem autorizou o quê, a resposta está no registro. Não depende de memória humana, não depende de arquivo manual, não depende de reconstituição posterior a partir de dados fragmentados.

Software com trilha nativa é aquele em que essa capacidade foi desenhada desde o início, integrada em cada operação. Software com trilha adicionada depois frequentemente tem cobertura parcial: alguns eventos são registrados, outros não, e a completude precisa ser verificada caso a caso. A diferença entre os dois padrões só aparece claramente quando alguma investigação real acontece.

Segregação de função no desenho do sistema

Segregação de função é princípio antigo de controle interno: quem executa uma etapa do processo não deve executar outra etapa que a controlaria. Aplicado à gestão de despesas corporativas, o princípio se traduz em sequência clara: quem presta contas não é quem aprova, quem aprova não é quem confere a nota fiscal, quem confere a nota não é quem processa o pagamento. Embora quem processa o pagamento eventualmente possa ser quem concilia o registro contábil.

Cada uma dessas separações existe por razão específica. Quem presta contas tem interesse em que a despesa seja aceita, portanto não pode ser o mesmo que aprova. Quem aprova tem interesse em manter fluxo rápido de trabalho, portanto não pode ser o único conferente da conformidade fiscal do documento. Quem confere fiscalmente tem interesse em fechar o mês, portanto não pode ser o único responsável pelo pagamento. Cada camada de separação reduz o risco de erro não intencional e de fraude intencional.

Em sistema humano baseado em planilha, a segregação depende de disciplina. As pessoas precisam se lembrar de que não podem exercer duas funções incompatíveis. Em software corporativo bem desenhado, a segregação é imposta pelo sistema. O usuário que cadastrou uma despesa não pode aprovar essa mesma despesa. O usuário que aprovou não pode conferir a nota fiscal. O usuário que conferiu não pode processar o pagamento. As restrições são configuradas em regras de sistema, e não podem ser contornadas por comportamento individual. Quando exceção é necessária ela é registrada explicitamente, com quem autorizou, quando, e com que justificativa.

Vale reconhecer honestamente que segregação rígida nem sempre é possível ou desejável. Empresa com poucos funcionários pode simplesmente não ter pessoas suficientes para segregar todas as funções que a referência do mercado propõe. Empresa em setor específico pode ter fluxo de trabalho onde algumas separações não fazem sentido. Software maduro permite configuração menos rígida quando o cliente decide, mas registra a decisão como configuração explícita, não como omissão silenciosa. A auditoria posterior pode consultar o registro e entender por que determinada empresa opera com segregação parcial em determinada função.

Controles preventivos e controles corretivos

Controle preventivo é aquele que impede que determinado comportamento aconteça. Controle corretivo é aquele que detecta o comportamento depois que aconteceu, e permite ação a partir da detecção. Os dois tipos são complementares, e sistema bem desenhado usa ambos, mas favorece o preventivo onde possível.

Exemplos de controle preventivo em gestão de despesas corporativas: cartão corporativo que não autoriza compra em categoria fora da política; limite de valor que impede lançamento acima de determinado teto sem aprovação especial; segregação de função imposta pelo sistema, conforme descrito na seção anterior; exigência de comprovante fiscal antes que a despesa possa avançar no fluxo; bloqueio automático de cartão quando funcionário acumula pendências além de determinado número.

Exemplos de controle corretivo: relatório periódico que sinaliza despesas fora do padrão da categoria; análise de anomalia que identifica funcionário com padrão de gasto atípico em relação a pares; conciliação bancária que sinaliza divergência entre valor cobrado e valor declarado; auditoria interna periódica que revisa amostra de despesas aprovadas para verificar aderência a política.

A diferença prática entre os dois tipos é significativa. Controle preventivo evita o problema. Controle corretivo detecta depois que o problema aconteceu. Do ponto de vista de resultado, o preventivo é sempre preferível quando é viável, porque evita esforço de investigação, evita conflito com funcionário, evita necessidade de recuperação de dinheiro que já foi gasto.

Mas nem todo problema é evitável por controle preventivo. Fraude sofisticada, com conluio interno ou com estabelecimento cúmplice, frequentemente contorna controles preventivos porque foi desenhada para operar dentro das regras aparentes. Erros de classificação por interpretação subjetiva de política podem passar pelo preventivo porque o sistema não consegue julgar intenção. Nesse território, o controle corretivo é indispensável.

Software corporativo maduro é honesto sobre essa distinção. Implementa o preventivo onde o preventivo funciona, com clareza sobre o que exatamente impede e o que exatamente permite. Implementa o corretivo onde o preventivo não alcança, com sinalização que permite ao cliente decidir o nível de atenção. Não vende um como se fosse o outro. Não promete que o preventivo elimina necessidade do corretivo, e não promete que o corretivo substitui a função do preventivo.

Software corporativo imaturo, em contraste, frequentemente promete controle absoluto por meio de recurso único (seja “aprovação automatizada”, seja “detecção por inteligência artificial”, seja outro termo do momento) que pretende cobrir todas as dimensões. A promessa não se sustenta na prática, e o cliente que compra baseado na promessa descobre depois que precisa complementar com outros controles que o fornecedor não mencionou.

Controlador e operador na regulação de dados

Regulação de proteção de dados pessoais no Brasil, na Europa e em outras jurisdições distingue dois papéis fundamentais. O controlador é a organização que decide para que e como os dados pessoais são tratados. O operador é a organização que processa os dados em nome do controlador, seguindo as instruções dele. A distinção é técnica, tem consequências jurídicas específicas, e é frequentemente confundida no discurso comercial de software corporativo.

Aplicado à gestão de despesas corporativas, o quadro é o seguinte. A empresa cliente (aquela que emprega os funcionários cujas despesas são gerenciadas) é o controlador. Ela decide que dados coleta dos funcionários (dados bancários, CPF, endereço, dados de cartão corporativo), com que finalidade (processar reembolso, integrar contabilmente, atender obrigação fiscal), e por quanto tempo os mantém. A responsabilidade primária pelo cumprimento da regulação de proteção de dados é dela.

O software de gestão de despesas é o operador. Ele processa os dados que a empresa cliente fornece, sob as instruções que a empresa cliente estabelece, para as finalidades que a empresa cliente definiu. Sua responsabilidade é técnica: garantir que o processamento aconteça com as medidas de segurança adequadas, que o acesso aos dados seja restrito conforme configurado, que a retenção respeite os prazos estabelecidos, que o expurgo aconteça quando o cliente deixa de contratar o serviço.

Essa distinção importa por três razões práticas.

1. O discurso comercial que insinua “usar nosso software resolve compliance de LGPD” é falso. Software não resolve compliance de LGPD para o cliente, porque a maior parte da responsabilidade de LGPD é do cliente. Software resolve a parte que cabe ao operador: segurança técnica, restrição de acesso, retenção, expurgo. O restante é decisão e responsabilidade de quem contrata o software.

2. O cliente que entende essa distinção avalia software com critérios corretos. Não pergunta “vocês são compliance com LGPD?” (pergunta imprecisa). Pergunta “vocês têm as medidas técnicas e organizacionais que a LGPD exige do operador?” e “como vocês suportam as decisões que preciso tomar como controlador?” (perguntas técnicas e precisas).

3. A mesma lógica se aplica a outras jurisdições. GDPR na Europa opera com distinção equivalente entre controller e processor. Regulações emergentes em outros países da América Latina seguem padrão similar. Software que opera em múltiplas jurisdições precisa entender essa arquitetura regulatória e comunicar claramente onde termina a responsabilidade do operador e onde começa a responsabilidade do controlador.

Isso não é evasão de responsabilidade. É clareza sobre onde a responsabilidade efetivamente reside. Software operador competente cumpre sua parte com rigor e apoia o controlador a cumprir a parte dele com informação e ferramentas adequadas. É diferente de software que promete o que não pode entregar.

Certificação como sinal, não como bala de prata

Certificações de segurança da informação e de compliance específico têm função legítima no mercado de software corporativo. ISO 27001 sinaliza que a organização opera com sistema de gestão de segurança da informação estruturado, com processos definidos, com revisão periódica, com auditoria externa que verifica aderência ao padrão. PCI DSS sinaliza que a organização trata dados de cartão de pagamento conforme padrões estabelecidos pela indústria de meios de pagamento, com controles técnicos específicos exigidos pelo padrão.

Essas certificações sinalizam que uma estrutura existe. A organização tem processos documentados, tem controles implementados, tem auditoria externa que verifica esses processos e controles com regularidade estabelecida. Isso é informação relevante para cliente que precisa avaliar risco de contratar o software, e é frequentemente exigida por auditoria interna do próprio cliente como parte da avaliação de fornecedor.

Porém, não substituem julgamento técnico do cliente sobre outros riscos que a certificação não cobre. ISO 27001 não avalia adequação funcional do software ao problema do cliente. PCI DSS não avalia usabilidade, integração com sistemas legados, ou outras dimensões que também importam. A certificação é sinal em uma dimensão específica, e a decisão completa também exige avaliação em outras dimensões.

O Dinnero tem certificação ISO 27001 e certificação PCI DSS. As certificações existem porque cliente enterprise em vários setores exige evidência formal, porque auditoria interna do cliente pede documentação padronizada, e porque é padrão de mercado nos segmentos onde o Dinnero opera. Elas são comunicadas quando faz sentido comunicá-las. Não são bandeira central do produto, porque o produto não depende só delas para valer o que vale.

O que faz o produto valer o que vale é o que está descrito nas seções anteriores deste artigo: trilha de auditoria bem desenhada, segregação de função no sistema, controles preventivos onde eles alcançam e corretivos onde eles são necessários, clareza sobre papel de operador. As certificações refletem estrutura que sustenta essas capacidades, mas não são as capacidades em si.

Compliance como resultado composto

O argumento central é que compliance real em gestão de despesas corporativas é resultado composto de cinco dimensões operando juntas: arquitetura técnica correta, disciplina de trilha de auditoria, segregação de função no desenho, uso apropriado de controles preventivos e corretivos, clareza sobre papel de operador em regulação de dados. Nenhuma das cinco, isolada, produz compliance. As cinco juntas, sustentadas ao longo do tempo, produzem.

A implicação prática é que compliance não é produto que se compra pronto. É estado operacional que se sustenta por escolhas contínuas de arquitetura, de configuração, de cultura interna do cliente, e de execução cotidiana. Software corporativo entrega uma parte: a parte estrutural, a parte técnica, a parte que cabe ao operador competente. O restante é do cliente, e permanece do cliente por definição regulatória e por natureza do problema.

Isso não diminui o papel do software. Ao contrário, coloca o papel no lugar correto. Software com trilha de auditoria bem desenhada faz o cliente ganhar tempo em qualquer investigação. Software com segregação de função no desenho impede erro não intencional e desestimula a fraude. Software com controles preventivos bem calibrados evita problema antes que aconteça. Software com clareza sobre papel de operador simplifica a arquitetura regulatória do cliente. Cada uma dessas contribuições é substantiva.

Mas software não é bandeira que a empresa hasteia para dizer que está em compliance. É estrutura técnica que sustenta a operação de compliance que a empresa faz. A diferença entre as duas coisas parece sutil na apresentação comercial e é enorme na operação real. Reconhecer isso é o primeiro passo de qualquer conversa séria sobre segurança e compliance em software corporativo.