Retenção de logs e DLR em SMS A2P: prazos, acesso e eliminação rastreável
Guia prático para definir uma política de retenção de logs e DLR de SMS A2P com base em finalidade, minimização, acesso restrito, rastreabilidade e eliminação verificável.
A retenção de registos SMS é uma decisão de operação, segurança e governação
A retenção de logs e DLR de SMS A2P não deve ser resolvida com um único prazo aplicado a todos os dados. Um envio gera evidências úteis para suporte, reconciliação, investigação de fraude, análise de qualidade, resolução de incidentes e defesa de reclamações. Ao mesmo tempo, parte dessas evidências pode incluir dados pessoais, conteúdo ou informação que facilite a reidentificação de uma pessoa ou de uma campanha.
Quando o RGPD se aplica, os princípios de limitação da finalidade, minimização e limitação do prazo de conservação exigem que os dados identificáveis sejam mantidos apenas durante o tempo necessário para finalidades específicas, explícitas e legítimas. As obrigações setoriais, fiscais, contratuais, regulamentares ou processuais aplicáveis a cada organização também podem afetar a decisão.
Uma política defensável não é a que conserva mais dados durante mais tempo. É a que consegue explicar, para cada classe de registo, que finalidade serve, quem precisa dele, que acesso recebe, quando muda de nível de acesso e como é eliminado ou anonimizado quando deixa de ser necessário.
- Defina a finalidade antes de estabelecer o prazo.
- Trate separadamente conteúdo, números, identificadores, metadados e eventos técnicos.
- Identifique as obrigações aplicáveis por jurisdição, contrato e função empresarial.
- Atribua responsáveis pela aprovação, execução e revisão da política.
- Valide, com aconselhamento jurídico e de privacidade, os prazos e as exceções aplicáveis à sua organização.
Que evidências gera um envio de SMS A2P
Um inventário de retenção começa por seguir o ciclo de vida técnico de uma mensagem. O pedido inicial pode conter dados da conta, credenciais ou contexto de integração, destino, remetente, conteúdo, parâmetros de envio e identificadores gerados pelo cliente ou pela plataforma. A aceitação técnica pode produzir um identificador de mensagem, um carimbo temporal e um resultado de validação ou de colocação em fila.
Durante o encaminhamento e o processamento, podem surgir decisões operacionais, códigos de erro, tentativas, alterações de estado, referências do fornecedor ou da rede e carimbos temporais. Posteriormente, podem ser recebidos callbacks ou DLR. A reconciliação acrescenta registos que associam pedidos, estados, resultados, consumo e eventuais litígios.
Nem todos estes elementos devem ser conservados em conjunto nem durante o mesmo período. Uma equipa de suporte pode necessitar de um identificador de correlação e de uma sequência de estados sem precisar do corpo completo do SMS. Uma equipa financeira pode necessitar de evidência de eventos faturáveis, enquanto uma análise de qualidade pode basear-se em dados agregados ou pseudonimizados.
- Pedido: conta ou contexto do cliente, destino, remetente, parâmetros, conteúdo e ID de origem, quando existam.
- Aceitação: ID da mensagem, hora, validações e resultado de admissão.
- Processamento: eventos de colocação em fila, encaminhamento, erros, novas tentativas e alterações de estado.
- DLR e callbacks: estado comunicado, hora de receção, referência correlacionável e origem técnica do evento.
- Reconciliação: ligações entre pedido, eventos, resultado e registos administrativos necessários.
O que significa um DLR e o que não comprova
Um DLR deve ser tratado como um evento de estado comunicado pela infraestrutura SMS. A especificação 3GPP TS 23.040 descreve o SMS-STATUS-REPORT como um relatório emitido pelo centro de serviço quando o estado da mensagem é concluído, com resultados que incluem a entrega bem-sucedida ao SME ou a impossibilidade de reencaminhamento devido a erros temporários ou permanentes.
Este registo é valioso para operação e reconciliação, mas não equivale necessariamente a uma prova independente de que uma pessoa leu, compreendeu ou agiu com base na mensagem. A semântica exata do estado recebido deve ser conservada juntamente com a fonte, a hora, a referência da mensagem e qualquer transformação aplicada internamente.
Além disso, a disponibilidade de relatórios de estado é opcional no serviço SMS. Por isso, a ausência de um DLR não deve transformar-se automaticamente numa conclusão sobre a entrega final. Uma política madura distingue entre “não foi recebido DLR”, “foi recebido um estado comunicado”, “o estado foi normalizado internamente” e “existe evidência adicional independente”, caso exista.
- Registe o valor original do estado sempre que possível.
- Conserve a fonte técnica e o carimbo temporal de receção do DLR.
- Documente as regras de normalização de estados para evitar interpretações ambíguas.
- Não apresente um DLR como evidência de leitura, compreensão, consentimento ou conversão.
- Não classifique a ausência de DLR como falha ou sucesso conclusivo sem o contexto técnico aplicável.
Crie um inventário mínimo e classifique os dados
O inventário deve ser suficientemente detalhado para decidir a retenção e o acesso, mas suficientemente prático para se manter atualizado. Uma classificação útil separa o conteúdo da mensagem, identificadores pessoais ou potencialmente identificáveis, metadados de encaminhamento, eventos técnicos, dados da conta e dados de controlo.
O conteúdo exige, normalmente, uma análise especialmente rigorosa. Pode incluir OTP, notificações transacionais, referências a encomendas, informação comercial ou outros dados sensíveis, conforme o caso de utilização. Conservá-lo por defeito para depuração alargada aumenta a exposição e não deve ser justificado apenas por conveniência operacional.
Os identificadores de correlação permitem reduzir a necessidade de mostrar dados sensíveis em painéis, pedidos de suporte ou exportações. A TS 23.040 prevê referências de mensagem que associam operações relacionadas, oferecendo uma base técnica para correlacionar pedido e estado sem reproduzir o conteúdo em cada visualização.
- Conteúdo: corpo do SMS, modelos, variáveis e anexos de contexto, quando existirem.
- Identificadores: ID da mensagem, ID do cliente, referência do fornecedor, referência da campanha ou correlação.
- Metadados: origem, destino, remetente, rota ou contexto de encaminhamento, carimbos temporais e parâmetros técnicos.
- Eventos técnicos: aceitação, estado, códigos de erro, callback, nova tentativa e resultado do processamento.
- Dados da conta e controlo: utilizador, função, organização, alterações de configuração, consultas e exportações.
Associe cada categoria a uma finalidade concreta
A finalidade determina o que conservar e durante quanto tempo. O suporte pode necessitar de reconstruir um incidente específico; a faturação e a reconciliação podem exigir evidência de eventos relevantes; a fraude e a segurança podem exigir sinais para investigar comportamentos anómalos; a qualidade pode necessitar de séries de estados e latências; a auditoria pode exigir registos de acesso e alterações; e uma reclamação pode exigir a preservação de um conjunto delimitado de evidências.
A chave é evitar finalidades genéricas, como “para o caso de ser necessário” ou “para análise futura”. Descreva a utilização operacional, o responsável, a população de dados, o prazo proposto e a razão pela qual uma versão menos identificável não é suficiente. Quando viável, substitua dados de eventos por métricas agregadas, contagens ou conjuntos pseudonimizados.
Os pedidos de cancelamento ou revogação também merecem uma categoria específica. Nos Estados Unidos, a FCC reconhece determinadas respostas por SMS, incluindo “stop”, “quit”, “end”, “revoke”, “opt out”, “cancel” e “unsubscribe”, como meios razoáveis para revogar o consentimento nos casos abrangidos pela sua decisão. A sua organização deve avaliar as regras aplicáveis, mas, operacionalmente, é aconselhável registar a receção, o processamento e o resultado destes eventos de forma controlada.
- Suporte: resolver um incidente delimitado e verificar sequências de eventos.
- Reconciliação: relacionar pedidos, estados e registos administrativos relevantes.
- Fraude e segurança: investigar anomalias com acesso proporcional e rastreável.
- Qualidade: analisar a consistência dos DLR, disponibilidade, erros e comportamento técnico com dados minimizados.
- Auditoria: demonstrar quem acedeu, alterou uma configuração ou executou uma exportação.
- Reclamações e obrigações: preservar apenas o âmbito necessário e com uma data de revisão.
Aplique um modelo por fases: ativo, arquivo restrito e disposição final
Um modelo por fases ajuda a evitar que todos os registos permaneçam indefinidamente em sistemas operacionais. A fase ativa contém os dados necessários para monitorização, suporte diário, investigação imediata e processos operacionais. Deve incluir o menor conjunto de dados e utilizadores compatível com essas tarefas.
Depois de terminar a necessidade operacional imediata, certos registos podem passar para um arquivo restrito se persistir uma finalidade documentada, como reconciliação, uma obrigação aplicável, um litígio concreto ou uma investigação em curso. O arquivo não é uma extensão automática da produção: deve reduzir as funções com acesso, limitar as capacidades de consulta e impedir que a informação seja usada para novas finalidades não aprovadas.
Quando a finalidade e qualquer exceção válida terminarem, aplique eliminação, anonimização ou agregação, de acordo com o resultado necessário. O NIST orienta a gestão de logs como um processo organizacional contínuo, e as suas diretrizes de sanitização salientam que a eliminação eficaz requer medidas adequadas à sensibilidade e validação da disposição final.
- Fase ativa: disponibilidade para a operação diária com acesso baseado em funções.
- Arquivo restrito: acesso excecional, justificado e registado.
- Disposição final: eliminação verificável, anonimização irreversível quando aplicável ou agregação sem necessidade identificável.
- Revisão: verifique periodicamente que os registos não permanecem numa fase por inércia.
- Exceção: aplique retenção limitada a um conjunto delimitado, com responsável e data de reavaliação.
Como definir prazos sem copiar um número arbitrário
Não existe um prazo universal tecnicamente válido para logs, DLR ou conteúdo SMS. A decisão deve partir da finalidade concreta e ser confrontada com as obrigações jurídicas, regulamentares, fiscais, contratuais e processuais aplicáveis. O facto de uma categoria ser útil não justifica a sua conservação indefinida; do mesmo modo, um prazo habitual no setor não substitui uma análise documentada.
Para cada categoria, formule perguntas verificáveis: que decisão, incidente ou processo pode ser resolvido com este dado? Quando deixa de ser necessário para essa finalidade? Existe uma obrigação aplicável que exija ou permita a sua conservação? É possível atingir a finalidade com dados pseudonimizados, agregados ou com menos campos? Que prejuízo resultaria de uma eliminação prematura, comparado com a exposição adicional de conservar os dados?
Documente o raciocínio, e não apenas o resultado. Se o prazo variar por tipo de cliente, jurisdição, produto, contrato ou classe de tráfego, a política deve refletir essas diferenças e o mecanismo técnico que as aplica.
- Finalidade e população exata de dados.
- Obrigações e compromissos aplicáveis, validados pelas funções responsáveis.
- Necessidade operacional real e janela temporal de utilização.
- Alternativas menos identificáveis, como pseudonimização ou agregação.
- Riscos de privacidade, segurança, fraude, reclamações e perda de evidência.
- Capacidade técnica para aplicar o prazo de forma consistente em sistemas, réplicas e cópias.
- Responsável pela decisão, data de aprovação e data de revisão.
Controle o acesso e reduza a exposição do conteúdo
Os logs não são automaticamente inofensivos. Uma combinação de destino, hora, remetente, identificador da conta e resultado de entrega pode revelar padrões de atividade. O conteúdo pode aumentar significativamente o risco. Por isso, o acesso deve basear-se em funções, necessidade de conhecimento e segregação de funções.
Um operador de suporte não deve receber, por defeito, as mesmas capacidades que um administrador de segurança, um responsável de reconciliação ou uma pessoa autorizada a responder a um pedido jurídico. Conceba visualizações com campos minimizados: por exemplo, identificadores de correlação, estados e carimbos temporais, em vez de conteúdo completo ou exportações em massa.
Registe consultas sensíveis, acessos excecionais, pesquisas por identificadores pessoais, alterações de retenção e exportações. A rastreabilidade do acesso serve tanto a segurança como a responsabilização. Reveja periodicamente permissões, contas privilegiadas e justificações de acesso.
- Aplique funções diferenciadas para suporte, operações, segurança, privacidade, finanças e administração.
- Mostre o conteúdo apenas quando for necessário para um caso autorizado.
- Utilize mascaramento ou redução de campos em painéis e pedidos de suporte, quando viável.
- Exija justificação e registo para o acesso excecional a dados sensíveis.
- Limite exportações, registe a sua execução e proteja o destino dos dados exportados.
- Reveja periodicamente permissões e acessos privilegiados.
Perguntas frequentes
Existe um prazo padrão para conservar logs e DLR de SMS A2P?
Não. O prazo deve depender da finalidade, das obrigações aplicáveis e da avaliação jurídica e operacional de cada organização. Quando o RGPD se aplica, os dados pessoais identificáveis devem ser conservados apenas durante o tempo necessário para as finalidades do tratamento.
Um DLR confirma que o destinatário leu o SMS?
Não. Um DLR é um evento de estado comunicado pela infraestrutura SMS. Pode ser útil para operação e reconciliação, mas não prova de forma independente que uma pessoa leu, compreendeu ou agiu com base na mensagem.
A ausência de DLR prova que a mensagem não foi entregue?
Não necessariamente. A capacidade de relatórios de estado é opcional no SMS. A ausência de um DLR deve ser registada como ausência desse evento, e não interpretada automaticamente como prova conclusiva de falha na entrega.
O conteúdo do SMS deve ser conservado para resolver incidentes?
Não por defeito. Avalie se o incidente pode ser resolvido com identificadores de correlação, estados, carimbos temporais, códigos de erro e metadados minimizados. O conteúdo deve ter controlos e acesso mais restritivos quando for realmente necessário.
Eliminar um registo da base de dados principal garante a eliminação?
Não por si só. Também devem ser consideradas réplicas, arquivos, cópias de segurança, exportações e outros suportes. A eliminação deve seguir controlos de sanitização adequados e verificações que demonstrem que a disposição final foi executada de acordo com a política.
O que deve incluir uma exceção de conservação?
No mínimo, o conjunto de dados afetado, a finalidade concreta, o responsável, a base aplicável, as funções autorizadas, a data de início, a data de revisão e o evento que permite encerrar a exceção. Uma exceção não deve transformar-se numa conservação indefinida e generalizada.
Fontes consultadas
- GDPR — principios de limitación de finalidad, minimización y limitación del plazo de conservación (artículo 5)EUR-Lex / Unión Europea
- 3GPP TS 23.040 — capacidades de informes de estado SMS y relación con referencias de mensaje3GPP / ETSI
- NIST SP 800-92 — Guide to Computer Security Log ManagementNational Institute of Standards and Technology
- NIST SP 800-88 Rev. 2 — Guidelines for Media SanitizationNational Institute of Standards and Technology
- FCC 24-24 — revocación de consentimiento mediante respuesta por SMSFederal Communications Commission
- NIST Privacy FrameworkNational Institute of Standards and Technology
- NIST SP 800-63-4 — Digital Identity GuidelinesNational Institute of Standards and Technology