Retención de logs y DLR en A2P SMS: plazos, acceso y borrado con trazabilidad
Guía práctica para definir una política de retención de logs y DLR A2P SMS basada en finalidad, minimización, acceso restringido, trazabilidad y borrado verificable.
La retención de registros SMS es una decisión de operación, seguridad y gobierno
La retención de logs y DLR A2P SMS no debe resolverse con una cifra única aplicada a todos los datos. Un envío genera evidencias útiles para soporte, conciliación, investigación de fraude, análisis de calidad, resolución de incidencias y defensa de reclamaciones. Al mismo tiempo, parte de esas evidencias puede incluir datos personales, contenido o información que facilite la reidentificación de una persona o de una campaña.
Cuando aplica el GDPR, los principios de limitación de finalidad, minimización y limitación del plazo de conservación exigen que los datos identificables se mantengan solo durante el tiempo necesario para finalidades específicas, explícitas y legítimas. Las obligaciones sectoriales, fiscales, contractuales, regulatorias o procesales que correspondan a cada organización también pueden afectar la decisión.
La política defendible no es la que conserva más datos durante más tiempo. Es la que puede explicar, para cada clase de registro, qué finalidad sirve, quién la necesita, qué acceso recibe, cuándo cambia de nivel de acceso y cómo se elimina o anonimiza al terminar su necesidad.
- Defina la finalidad antes de establecer el plazo.
- Trate por separado contenido, números, identificadores, metadatos y eventos técnicos.
- Identifique obligaciones aplicables por jurisdicción, contrato y función empresarial.
- Asigne propietarios responsables de aprobar, ejecutar y revisar la política.
- Valide con asesoramiento jurídico y de privacidad los plazos y excepciones que apliquen a su organización.
Qué evidencias genera un envío A2P SMS
Un inventario de retención comienza siguiendo el ciclo de vida técnico de un mensaje. La solicitud inicial puede contener datos de cuenta, credenciales o contexto de integración, destino, remitente, contenido, parámetros de envío e identificadores generados por el cliente o por la plataforma. La aceptación técnica puede producir un identificador de mensaje, una marca temporal y un resultado de validación o encolado.
Durante el encaminamiento y el procesamiento pueden aparecer decisiones operativas, códigos de error, intentos, cambios de estado, referencias del proveedor o de la red y marcas de tiempo. Después, pueden recibirse callbacks o DLR. La conciliación añade registros que vinculan solicitudes, estados, resultados, consumo y posibles disputas.
No todos esos elementos deben conservarse juntos ni durante el mismo periodo. Un equipo de soporte puede necesitar un identificador de correlación y una secuencia de estados sin requerir el cuerpo completo del SMS. Un equipo financiero puede requerir evidencia de eventos facturables, mientras que un análisis de calidad puede apoyarse en datos agregados o seudonimizados.
- Solicitud: cuenta o contexto de cliente, destino, remitente, parámetros, contenido e ID de origen cuando existan.
- Aceptación: ID de mensaje, hora, validaciones y resultado de admisión.
- Procesamiento: eventos de encolado, encaminamiento, errores, reintentos y cambios de estado.
- DLR y callbacks: estado informado, hora de recepción, referencia correlacionable y origen técnico del evento.
- Conciliación: vínculos entre solicitud, eventos, resultado y registros administrativos necesarios.
Qué significa un DLR y qué no demuestra
Un DLR debe tratarse como un evento de estado comunicado por la infraestructura SMS. La especificación 3GPP TS 23.040 describe el SMS-STATUS-REPORT como un informe emitido por el centro de servicio al concluir el estado del mensaje, con resultados que incluyen la entrega satisfactoria al SME o la imposibilidad de reenvío por errores temporales o permanentes.
Este registro es valioso para operación y conciliación, pero no equivale necesariamente a una prueba independiente de que una persona leyó, comprendió o actuó sobre el mensaje. La semántica exacta del estado recibido debe conservarse junto con la fuente, la hora, la referencia del mensaje y cualquier transformación aplicada internamente.
Además, la disponibilidad de informes de estado es opcional en el servicio SMS. Por ello, la ausencia de un DLR no debe convertirse automáticamente en una conclusión sobre la entrega final. Una política madura distingue entre “no se recibió DLR”, “se recibió un estado comunicado”, “el estado fue normalizado internamente” y “existe evidencia adicional independiente”, si la hubiera.
- Registre el valor original del estado cuando sea posible.
- Conserve la fuente técnica y la marca temporal de recepción del DLR.
- Documente las reglas de normalización de estados para evitar interpretaciones ambiguas.
- No presente un DLR como evidencia de lectura, comprensión, consentimiento o conversión.
- No clasifique la ausencia de DLR como fallo o éxito concluyente sin el contexto técnico aplicable.
Construya un inventario mínimo y clasifique los datos
El inventario debe ser lo bastante detallado para decidir retención y acceso, pero lo bastante práctico para mantenerse actualizado. Una clasificación útil separa contenido del mensaje, identificadores personales o potencialmente identificables, metadatos de encaminamiento, eventos técnicos, datos de cuenta y datos de control.
El contenido suele requerir un examen especialmente estricto. Puede incluir OTP, avisos transaccionales, referencias a pedidos, información comercial u otros datos sensibles según el caso de uso. Retenerlo por defecto para depuración amplia aumenta exposición y no debe justificarse solo por comodidad operativa.
Los identificadores de correlación permiten reducir la necesidad de mostrar datos sensibles en paneles, tickets o exportaciones. TS 23.040 contempla referencias de mensaje que vinculan operaciones relacionadas, lo que ofrece una base técnica para correlacionar solicitud y estado sin reproducir el contenido en cada vista.
- Contenido: cuerpo del SMS, plantillas, variables y adjuntos de contexto si existen.
- Identificadores: ID de mensaje, ID de cliente, referencia de proveedor, referencia de campaña o correlación.
- Metadatos: origen, destino, remitente, ruta o contexto de encaminamiento, marcas de tiempo y parámetros técnicos.
- Eventos técnicos: aceptación, estado, códigos de error, callback, reintento y resultado de procesamiento.
- Datos de cuenta y control: usuario, rol, organización, cambios de configuración, consultas y exportaciones.
Vincule cada categoría a una finalidad concreta
La finalidad determina qué conservar y durante cuánto tiempo. Soporte puede necesitar reconstruir una incidencia concreta; facturación y conciliación pueden requerir evidencia de eventos relevantes; fraude y seguridad pueden requerir señales para investigar comportamientos anómalos; calidad puede necesitar series de estados y latencias; auditoría puede requerir registros de acceso y de cambios; y una reclamación puede exigir preservar un conjunto delimitado de evidencias.
La clave es evitar finalidades genéricas como “por si acaso” o “para análisis futuro”. Describa el uso operativo, el propietario, la población de datos, el plazo propuesto y el motivo por el que no basta una versión menos identificable. Cuando sea viable, sustituya datos de evento por métricas agregadas, conteos o conjuntos seudonimizados.
Las solicitudes de baja o revocación también merecen una categoría específica. En Estados Unidos, la FCC reconoce determinadas respuestas por SMS, entre ellas “stop”, “quit”, “end”, “revoke”, “opt out”, “cancel” y “unsubscribe”, como medios razonables para revocar consentimiento en los casos cubiertos por su decisión. Su organización debe evaluar las reglas aplicables, pero operativamente conviene registrar la recepción, el procesamiento y el resultado de estos eventos de forma controlada.
- Soporte: resolver un incidente delimitado y verificar secuencias de eventos.
- Conciliación: relacionar solicitudes, estados y registros administrativos pertinentes.
- Fraude y seguridad: investigar anomalías con acceso proporcional y trazable.
- Calidad: analizar consistencia de DLR, disponibilidad, errores y comportamiento técnico con datos minimizados.
- Auditoría: demostrar quién accedió, modificó una configuración o ejecutó una exportación.
- Reclamaciones y obligaciones: preservar únicamente el alcance necesario y con una fecha de revisión.
Aplique un modelo por fases: activo, archivo restringido y disposición final
Un modelo por fases ayuda a evitar que todos los registros permanezcan indefinidamente en sistemas operativos. La fase activa contiene los datos necesarios para monitorización, soporte cotidiano, investigación inmediata y procesos operativos. Debe tener el menor conjunto de datos y usuarios compatible con esas tareas.
Al terminar la necesidad operativa inmediata, ciertos registros pueden pasar a un archivo restringido si persiste una finalidad documentada, como conciliación, una obligación aplicable, una disputa concreta o una investigación abierta. El archivo no es una extensión automática de la producción: debe reducir los roles con acceso, limitar las funciones de consulta y evitar que la información se use para finalidades nuevas no aprobadas.
Al finalizar la finalidad y cualquier excepción válida, aplique eliminación, anonimización o agregación según el resultado necesario. NIST orienta la gestión de logs como un proceso organizativo continuo, y sus directrices de sanitización subrayan que la eliminación efectiva requiere medidas apropiadas a la sensibilidad y validación de la disposición.
- Fase activa: disponibilidad para operación diaria bajo acceso basado en roles.
- Archivo restringido: acceso excepcional, justificado y registrado.
- Disposición final: borrado verificable, anonimización irreversible cuando proceda o agregación sin necesidad identificable.
- Revisión: compruebe periódicamente que los registros no permanecen en una fase por inercia.
- Excepción: aplique una retención limitada a un conjunto delimitado, con propietario y fecha de reevaluación.
Cómo definir plazos sin copiar una cifra arbitraria
No existe un plazo universal técnicamente válido para logs, DLR o contenido SMS. La decisión debe partir de la finalidad concreta y contrastarse con obligaciones jurídicas, regulatorias, fiscales, contractuales y procesales aplicables. El hecho de que una categoría sea útil no justifica conservarla indefinidamente; tampoco una cifra habitual en el sector sustituye un análisis documentado.
Para cada categoría, formule preguntas verificables: ¿qué decisión, incidente o proceso se puede resolver con este dato? ¿Cuándo deja de ser necesario para ese propósito? ¿Existe una obligación aplicable que exija o permita conservarlo? ¿Puede alcanzarse la finalidad con datos seudonimizados, agregados o con menos campos? ¿Qué perjuicio ocasionaría una eliminación prematura frente a la exposición adicional de conservarlo?
Documente el razonamiento, no solo el resultado. Si el plazo cambia por tipo de cliente, jurisdicción, producto, contrato o clase de tráfico, la política debe reflejar esas diferencias y el mecanismo técnico que las aplica.
- Finalidad y población exacta de datos.
- Obligaciones y compromisos aplicables, validados por las funciones responsables.
- Necesidad operativa real y ventana temporal de uso.
- Alternativas menos identificables, como seudonimización o agregación.
- Riesgos de privacidad, seguridad, fraude, reclamaciones y pérdida de evidencia.
- Capacidad técnica de aplicar el plazo de forma consistente en sistemas, réplicas y copias.
- Propietario de la decisión, fecha de aprobación y fecha de revisión.
Controle el acceso y reduzca la exposición del contenido
Los logs no son automáticamente inocuos. Una combinación de destino, hora, remitente, identificador de cuenta y resultado de entrega puede revelar patrones de actividad. El contenido puede aumentar significativamente el riesgo. Por ello, el acceso debe basarse en roles, necesidad de conocer y separación de funciones.
Un operador de soporte no debería recibir por defecto las mismas capacidades que un administrador de seguridad, un responsable de conciliación o una persona autorizada para responder a una solicitud jurídica. Diseñe vistas con campos minimizados: por ejemplo, identificadores de correlación, estados y marcas temporales antes que contenido completo o exportaciones masivas.
Registre las consultas sensibles, los accesos excepcionales, las búsquedas por identificadores personales, los cambios de retención y las exportaciones. La trazabilidad del acceso sirve tanto para seguridad como para rendición de cuentas. Revise periódicamente permisos, cuentas privilegiadas y justificaciones de acceso.
- Aplique roles diferenciados para soporte, operaciones, seguridad, privacidad, finanzas y administración.
- Muestre contenido solo cuando sea necesario para un caso autorizado.
- Use enmascaramiento o reducción de campos en paneles y tickets cuando sea viable.
- Exija justificación y registro para el acceso excepcional a datos sensibles.
- Limite exportaciones, registre su ejecución y proteja el destino de los datos exportados.
- Revise permisos y accesos privilegiados de forma periódica.
Preguntas frecuentes
¿Existe un plazo estándar para conservar logs y DLR A2P SMS?
No. El plazo debe depender de la finalidad, de las obligaciones aplicables y de la evaluación jurídica y operativa de cada organización. Cuando aplica el GDPR, los datos personales identificables deben conservarse solo durante el tiempo necesario para las finalidades del tratamiento.
¿Un DLR confirma que el destinatario leyó el SMS?
No. Un DLR es un evento de estado comunicado por la infraestructura SMS. Puede ser útil para operación y conciliación, pero no prueba de forma independiente que una persona leyó, comprendió o actuó sobre el mensaje.
¿La falta de DLR demuestra que el mensaje no se entregó?
No necesariamente. La capacidad de informes de estado es opcional en SMS. La ausencia de un DLR debe registrarse como ausencia de ese evento, no interpretarse automáticamente como prueba concluyente de fallo de entrega.
¿Debe conservarse el contenido del SMS para resolver incidencias?
No por defecto. Evalúe si la incidencia puede resolverse con identificadores de correlación, estados, marcas de tiempo, códigos de error y metadatos minimizados. El contenido debe tener controles y acceso más restrictivos cuando sea realmente necesario.
¿Borrar un registro de la base de datos principal garantiza la eliminación?
No por sí solo. También deben considerarse réplicas, archivos, copias de seguridad, exportaciones y otros soportes. La eliminación debe seguir controles de sanitización apropiados y verificaciones que demuestren que la disposición se ha ejecutado según la política.
¿Qué debe incluir una excepción de conservación?
Como mínimo, el conjunto de datos afectado, la finalidad concreta, el propietario, la base aplicable, los roles autorizados, la fecha de inicio, la fecha de revisión y el evento que permite cerrar la excepción. Una excepción no debe convertirse en una conservación indefinida y generalizada.
Fuentes 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