Retención de datos A2P SMS: cómo organizar registros y plazos
Una guía para inventariar datos A2P SMS, asignar finalidades y controles, y definir plazos de conservación sin aplicar periodos universales.
Por qué separar los datos de una cadena A2P SMS
Una operación A2P SMS puede generar distintos registros: contenido del mensaje, identificadores de transacción, números de origen y destino, marcas temporales, respuestas de sistemas, estados de entrega o evidencias asociadas al consentimiento. No todos cumplen la misma función ni necesitan el mismo acceso o plazo de conservación.
La política de retención debe responder, para cada categoría, qué dato se conserva, para qué finalidad, quién es responsable de decidirlo, quién puede acceder y cómo se elimina. La protección de datos por defecto ofrece un marco útil para diseñar esos tratamientos con criterios de privacidad desde el inicio; las medidas concretas deben ajustarse al contexto y a las obligaciones aplicables.
- Evita acumular datos «por si acaso» sin una finalidad documentada.
- No asumas que todos los participantes de la cadena —empresa remitente, agregador, proveedor o destinatario del tráfico— tienen las mismas responsabilidades.
- Documenta las decisiones y revisa la política cuando cambien los usos, sistemas o requisitos aplicables.
Inventariar categorías y finalidades
Empieza por dibujar el recorrido del mensaje y localizar qué sistemas generan o reciben registros. El inventario debe describir campos y usos reales, no categorías genéricas que oculten diferencias importantes. Por ejemplo, un identificador de transacción puede servir para investigar una incidencia, mientras que una evidencia de consentimiento puede apoyar la gestión de una autorización. Son finalidades distintas y conviene evaluarlas por separado.
El contenido del mensaje merece atención específica: puede incluir información sensible según el contexto, como un código de un solo uso o datos de una operación. Si no hace falta guardar el texto íntegro para una finalidad operativa, evalúa si basta con conservar un identificador, un estado o una referencia menos detallada.
- Contenido: cuerpo del SMS y, si existen, plantillas o variables utilizadas.
- Identificadores y metadatos: referencias de mensaje, origen y destino, marcas temporales y datos técnicos asociados.
- Estados y DLR: eventos o respuestas registrados por los sistemas, indicando su procedencia y significado operativo.
- Consentimiento: evidencia disponible, su fuente, fecha y relación con el destinatario o campaña.
- Para cada categoría, anota finalidad, sistema de origen, responsable de la decisión, usuarios autorizados y regla prevista de eliminación.
Definir plazos según finalidad y obligaciones
No existe en la información disponible una base para fijar un plazo universal de conservación aplicable a logs, DLR o evidencias de consentimiento A2P SMS. El periodo debe decidirse según la finalidad concreta, la jurisdicción, el papel de cada entidad y las obligaciones legales, regulatorias o contractuales que correspondan.
Para cada categoría, documenta por qué se necesita conservarla, qué hecho inicia el plazo y qué evento permite borrarla. Si una obligación exige mantener datos durante cierto periodo, registra la justificación y el alcance exacto, en lugar de prolongar automáticamente la conservación de todos los registros relacionados.
- Consulta a asesoría legal o de privacidad para validar los plazos en las jurisdicciones y sectores implicados.
- Separa los plazos por finalidad: investigación de fallos, conciliación operativa y gestión de consentimiento pueden requerir análisis distintos.
- Establece una revisión periódica para confirmar que la finalidad sigue vigente y que el plazo sigue justificado.
- Documenta las excepciones, como una retención legal, con alcance, responsable y condición de cierre.
Minimizar y separar contenido de metadatos
La minimización empieza al decidir qué se registra. Si una incidencia puede investigarse con un identificador y un estado, almacenar además el mensaje completo puede no ser necesario para esa finalidad. Considera separar el contenido de los metadatos operativos para que los equipos que consultan estados o concilian operaciones no accedan por defecto al texto del SMS.
Cuando sea compatible con el propósito y con las necesidades operativas, evalúa técnicas de seudonimización o reducción de identificadores directos. Estas medidas no convierten automáticamente los datos en anónimos ni eliminan la necesidad de protegerlos; su eficacia depende de cómo se implementen y de si es posible volver a asociarlos con una persona.
- Registra únicamente los campos necesarios para cada finalidad definida.
- Separa repositorios o vistas de contenido y metadatos cuando el diseño de los sistemas lo permita.
- Evalúa si se pueden reducir o seudonimizar identificadores sin impedir la operación legítima.
- Revisa si el contenido completo puede excluirse de logs, exportaciones y herramientas de soporte.
Limitar el acceso y las exportaciones
El acceso debe corresponder a una tarea concreta. El equipo que investiga fallos puede necesitar consultar registros técnicos, pero no necesariamente evidencias de consentimiento o contenido íntegro. La guía del EDPB recuerda que responsables y encargados deben aplicar medidas técnicas y organizativas adecuadas para proteger datos personales; el diseño de permisos debe reflejar esa obligación de forma práctica.
Define quién puede consultar cada categoría, con qué motivo y mediante qué mecanismo. Cuando sea viable, registra las consultas y limita las exportaciones, que pueden crear copias difíciles de controlar en equipos locales, tickets o herramientas de análisis.
- Asigna permisos por función y categoría de datos, no solo por pertenencia a un equipo.
- Exige una justificación operativa para accesos excepcionales a contenido o datos identificativos.
- Registra consultas y exportaciones cuando los sistemas y el contexto lo permitan.
- Revisa permisos y accesos periódicamente, incluidos los de cuentas de soporte y administración.
Planificar un borrado verificable
Una política no está completa si define plazos pero no explica cómo se ejecuta el borrado. Identifica dónde pueden quedar copias: sistemas activos, réplicas, exportaciones, herramientas de análisis y copias de seguridad. Las técnicas y posibilidades de eliminación dependen de la arquitectura; la información disponible no establece un método técnico único para A2P SMS.
Diseña un procedimiento que permita comprobar que la eliminación se ejecutó en los sistemas previstos y que trate las copias de seguridad de acuerdo con las capacidades y reglas aplicables. Si no es posible borrar de inmediato una copia concreta, documenta la limitación, las medidas para restringir su uso y el tratamiento previsto al restaurarla o al finalizar su ciclo.
- Mantén un mapa de sistemas y copias que pueden contener cada categoría.
- Automatiza la eliminación cuando sea viable y valida el resultado con controles adecuados.
- Documenta excepciones y límites técnicos en vez de prometer un borrado que el sistema no puede garantizar.
- Incluye reglas para evitar que datos eliminados vuelvan a incorporarse sin una finalidad válida.
Gestionar solicitudes y retenciones excepcionales
Las solicitudes de acceso o eliminación y las retenciones legales requieren procedimientos definidos, pero su alcance y tratamiento dependen de la jurisdicción y de las circunstancias. Consulta con asesoría competente para establecer cómo verificar, localizar y responder a cada solicitud, y cómo resolver posibles conflictos con obligaciones aplicables.
Mantén trazabilidad de las decisiones sin conservar innecesariamente los datos objeto de la solicitud. Si una retención impide el borrado de parte de la información, delimita qué registros quedan retenidos, por qué, quién aprobó la excepción y cuándo debe revisarse.
- Define un canal y responsables para recibir y coordinar solicitudes.
- Documenta las búsquedas realizadas, la decisión tomada y su fundamento.
- Limita las retenciones excepcionales a los datos y propósitos necesarios.
- Programa una revisión para cerrar la excepción cuando deje de ser aplicable.
Usar logs y DLR con límites claros
Los registros operativos pueden ayudar a reconstruir una incidencia o conciliar eventos entre sistemas, siempre que se conozca su origen y significado. Documenta qué componente genera cada estado y qué representa en ese flujo concreto. No atribuyas a todos los estados el mismo nivel de certeza.
Un DLR reportado no demuestra por sí solo que el mensaje se haya mostrado o recibido en el terminal, ni acredita el consentimiento del destinatario. Úsalo como una señal operativa dentro del contexto de la ruta y los sistemas implicados, no como prueba concluyente de recepción o autorización.
- Conserva la procedencia del evento y la hora registrada por el sistema que lo generó.
- Distingue entre mensajes enviados, respuestas de red o proveedor y recepción verificada de manera independiente, si esa verificación existe.
- No uses un estado de entrega para sustituir la evidencia de consentimiento.
- Al investigar fallos, combina los registros pertinentes sin ampliar la conservación de categorías ajenas a la incidencia.
Preguntas frecuentes
¿Cuánto tiempo deben conservarse los logs A2P SMS?
No hay un plazo universal que pueda recomendarse para todos los logs A2P SMS. Define el periodo por categoría y finalidad, y valídalo con asesoría legal según la jurisdicción y las obligaciones aplicables.
¿Un DLR demuestra que el SMS llegó al teléfono del destinatario?
No por sí solo. Un DLR reportado es un evento operativo cuya interpretación depende del sistema que lo genera; no debe presentarse automáticamente como prueba independiente de recepción en el terminal.
¿Un DLR sirve como prueba de consentimiento?
No. Un estado de entrega y una evidencia de consentimiento responden a cuestiones diferentes. El consentimiento debe gestionarse y documentarse según las reglas aplicables al caso.
¿Qué datos conviene separar en la política?
Como mínimo, evalúa por separado el contenido, los identificadores y marcas temporales, los estados y DLR, y las evidencias de consentimiento. Para cada categoría define finalidad, responsable, acceso, plazo y método de borrado.
¿Cómo se deben borrar los registros de las copias de seguridad?
Depende de la arquitectura y de las obligaciones aplicables. Identifica las copias, documenta las limitaciones técnicas y define controles para restringir el uso y tratar los datos al restaurar o al finalizar el ciclo de la copia.
Fuentes consultadas
- Guía de Protección de Datos por DefectoAgencia Española de Protección de Datos (AEPD)
- Datos personales segurosEuropean Data Protection Board (EDPB)