Evidências de roteamento de SMS A2P: retenção, acesso e exclusão

O que conta como evidência de uma decisão de roteamento

Evidência de roteamento é a informação necessária para explicar qual decisão foi tomada, com base em qual regra ou critério, quando foi aplicada e quem a autorizou ou modificou. Sua utilidade está em reconstruir o contexto de uma decisão operacional, revisão ou disputa; não consiste em conservar tudo o que os sistemas geram.

Pode ser pertinente documentar versões de políticas, parâmetros de avaliação, resultados de testes, aprovações e alterações efetivadas. Esta é uma proposta de inventário que cada organização deve confrontar com seus sistemas e obrigações: aqui não há uma lista técnica universal de campos obrigatórios para todas as plataformas de SMS A2P.

Os registros gerais do sistema, os DLRs e os dados de tráfego têm funções diferentes. Um DLR pode descrever um status informado pela rede ou por um intermediário, mas não comprova, por si só, o recebimento verificado no dispositivo. Da mesma forma, nem todo registro de tráfego constitui evidência do motivo pelo qual uma rota foi escolhida.

• Pergunta de projeto: quais dados permitem explicar a decisão e quais apenas descrevem a atividade posterior?
• Conserve a origem e o contexto necessários para interpretar uma evidência, não apenas um resultado isolado.
• Documente as limitações de cada fonte, especialmente quando o status vem de um DLR.

Separar políticas, aprovações, testes e dados de mensagens

É recomendável classificar as informações antes de atribuir prazos. Uma estrutura inicial distingue quatro grupos: configuração e alterações de políticas; aprovações e responsáveis; testes ou avaliações; e dados de tráfego, que podem conter identificadores, conteúdo ou outros dados pessoais. A classificação deve se adaptar ao que cada sistema realmente registra.

A evidência de uma regra pode ser conservada sem guardar o conteúdo das mensagens, caso uma referência, uma versão ou um resultado agregado seja suficiente. Mas não se deve presumir que a anonimização, a agregação ou a exclusão do conteúdo sejam sempre possíveis sem afetar uma investigação: isso precisa ser verificado com os processos e sistemas envolvidos.

Manter essas categorias separadas ajuda a evitar que uma necessidade de auditoria se transforme automaticamente em justificativa para reter dados de tráfego por tempo indeterminado.

• Política: regra aplicada, versão, escopo e período de vigência, se o sistema os registrar.
• Aprovação: decisão, função de quem aprovou e contexto suficiente para compreendê-la.
• Teste: método, condições, resultado e limitações conhecidas.
• Tráfego: campos operacionais necessários à finalidade, avaliados separadamente quanto à possível sensibilidade.

Criar um inventário útil e limitado

O inventário deve descrever dados e processos reais, não um modelo teórico. Para cada conjunto, identifique sua finalidade, sensibilidade, responsável funcional, sistema de origem, usuários que precisam de acesso e relação com outras evidências. Se um campo não tiver uma finalidade operacional ou de conformidade documentada, avalie se é necessário coletá-lo ou conservá-lo.

As informações disponíveis não indicam uma fonte técnica que estabeleça campos obrigatórios para reconstruir uma decisão de rota de SMS A2P. Por isso, os exemplos deste guia são perguntas de projeto, não um padrão nem uma obrigação normativa.

• Que decisão ou atividade este conjunto explica?
• Qual é a fonte e como ela se relaciona com a versão da política em vigor?
• Inclui conteúdo, identificadores ou dados pessoais, ou pode ser reduzido a uma referência?
• Quem é responsável por mantê-lo e quem deve poder consultá-lo?
• De que exportações, relatórios ou sistemas de terceiros ele depende?

Justificar os prazos de retenção sem presumir um prazo universal

Não existe um prazo universal de retenção para evidências de roteamento de SMS A2P que possa ser aplicado sem analisar o contexto. A duração deve ser justificada pelo uso previsto e confrontada com as obrigações legais, regulatórias e contratuais aplicáveis às partes e jurisdições envolvidas. As fontes disponíveis aqui não permitem definir um prazo específico.

Para cada categoria, documente por que é necessário conservá-la, qual evento inicia ou encerra essa necessidade e quem revisa o prazo. Uma regra de política pode ter uma necessidade diferente da de um registro de tráfego. Evite copiar automaticamente o prazo geral de retenção de logs ou DLRs: esses registros podem ter finalidades e riscos distintos.

Se uma disputa, investigação ou obrigação aplicável exigir a preservação de informações, o processo deve ter escopo e responsáveis definidos. A organização deve determinar como essa preservação se relaciona com a política habitual e quando poderá ser revista ou encerrada.

• Vincule cada prazo a uma finalidade documentada e às obrigações verificadas para o caso.
• Diferencie o período operacional normal de qualquer preservação excepcional.
• Revise os prazos quando mudarem as finalidades, os contratos, a regulamentação aplicável ou os sistemas.
• Não apresente uma recomendação interna como requisito legal universal.

Controlar o acesso com permissões definidas

O acesso deve corresponder a tarefas específicas. Como critério de projeto, atribua permissões por função e conceda apenas o necessário para administrar políticas, aprovar alterações, analisar incidentes ou conduzir revisões. A separação entre quem propõe uma alteração e quem a aprova pode ser útil, mas deve se ajustar ao porte, aos riscos e aos controles reais da organização.

Registre consultas e alterações quando os sistemas permitirem e houver uma finalidade definida para isso. Esses registros também são dados: inclua-os no inventário, limite o acesso e estabeleça uma revisão do prazo de retenção. As evidências disponíveis não permitem afirmar que uma plataforma específica de SMS A2P ofereça esses controles nativamente.

• Defina funções e ações permitidas; evite permissões amplas sem justificativa.
• Revise periodicamente as contas e permissões, especialmente após mudanças de função.
• Avalie a separação entre proposta, aprovação e execução de alterações.
• Trate os registros de consulta como informações que também precisam de finalidade e governança.

Projetar uma exclusão verificável, incluindo cópias e exportações

Uma política de exclusão deve especificar quais informações são removidas ou deixam de estar disponíveis, quem autoriza a operação, como sua execução é registrada e como as exceções de retenção são tratadas. Antes de excluir, verifique se há obrigações aplicáveis ou uma preservação documentada que afete o conjunto.

O escopo não termina necessariamente no repositório principal: verifique exportações, relatórios, armazenamento secundário e cópias de segurança. Não se deve prometer que as cópias de segurança serão apagadas imediatamente; seu ciclo e tratamento dependem da arquitetura e dos procedimentos de cada organização. Se uma cópia não puder ser alterada seletivamente, documente como seu acesso é controlado e como se evita reutilizar dados que deveriam deixar de estar disponíveis.

A verificação pode se basear em evidências do processo — por exemplo, registro da solicitação, escopo, execução, resultado e exceções — desde que a solução técnica permita obtê-las. Não afirme que uma marcação de exclusão equivale à remoção física de todas as cópias sem verificar esse comportamento.

• Identifique repositórios, exportações e cópias antes de iniciar o processo.
• Registre o escopo, o responsável, a data, o resultado e qualquer exceção.
• Verifique o significado técnico de “exclusão” em cada sistema.
• Defina como evitar a restauração ou reutilização de informações que já não devem estar disponíveis.

Responder a uma auditoria ou disputa com contexto e procedência

Uma resposta sólida não depende de acumular dados sem limite, mas de conseguir explicar a origem e o significado das evidências disponíveis. Prepare um procedimento para localizar a versão pertinente da política, relacioná-la às aprovações e aos testes relevantes e descrever quais dados de tráfego foram conservados, por quê e com quais limitações.

Quando faltarem informações ou uma fonte não permitir confirmar um fato, declare isso. Por exemplo, diferencie um status informado por um DLR de um recebimento verificado de forma independente. Se forem entregues informações a um auditor ou a uma contraparte, aplique as permissões e restrições contratuais e legais correspondentes; não compartilhe dados adicionais por conveniência.

• Identifique quem solicita as evidências, o escopo e a autoridade da solicitação.
• Reúna versões, aprovações, testes e referências necessárias para explicar a decisão.
• Registre a fonte, o período abrangido e as limitações dos dados.
• Minimize as informações de tráfego compartilhadas e documente o que foi entregue.

Lista de verificação para implementar uma política revisável

Comece com um escopo pequeno: identifique os processos decisórios que devem poder ser reconstruídos e os sistemas envolvidos. Em seguida, valide o inventário com as equipes de operações, segurança, privacidade e conformidade antes de definir permissões e prazos.

A política deve poder mudar quando as necessidades ou obrigações mudarem. Designe um responsável pela revisão e mantenha a justificativa das alterações; não transforme uma configuração inicial em regra permanente sem reavaliá-la.

• Definir quais decisões e processos a política abrange.
• Inventariar dados, fontes, sensibilidade, finalidade e responsáveis.
• Separar evidências de decisão de logs gerais, DLRs e dados de tráfego.
• Justificar cada prazo com base no uso e nas obrigações aplicáveis, sem impor um prazo universal.
• Atribuir acessos por função e revisar as permissões.
• Documentar preservação excepcional, exclusão, cópias e exportações.
• Preparar uma resposta de auditoria que preserve a procedência e explique as limitações.
• Definir uma revisão periódica e um responsável por manter a política.