Evidencias de enrutamiento A2P SMS: retención, acceso y borrado

Qué cuenta como evidencia de una decisión de enrutamiento

La evidencia de enrutamiento es la información necesaria para explicar qué decisión se tomó, con qué regla o criterio, cuándo se aplicó y quién la autorizó o modificó. Su utilidad es reconstruir el contexto de una decisión operativa, una revisión o una disputa; no consiste en conservar todo lo que generan los sistemas.

Puede ser pertinente documentar versiones de políticas, parámetros de evaluación, resultados de pruebas, aprobaciones y cambios efectivos. Esta es una propuesta de inventario que cada organización debe contrastar con sus sistemas y obligaciones: no existe aquí una lista técnica universal de campos exigibles para todas las plataformas A2P SMS.

Los registros generales de sistema, los DLR y los datos de tráfico cumplen funciones diferentes. Un DLR puede describir un estado comunicado por la red o por un intermediario, pero no demuestra por sí solo una recepción verificada en el dispositivo. Tampoco cada registro de tráfico constituye evidencia de por qué se eligió una ruta.

• Pregunta de diseño: ¿qué dato permite explicar la decisión y cuál solo describe actividad posterior?
• Conserva la procedencia y el contexto necesarios para interpretar una evidencia, no solo un resultado aislado.
• Documenta las limitaciones de cada fuente, especialmente cuando el estado procede de un DLR.

Separar política, aprobaciones, pruebas y datos de mensajes

Conviene clasificar la información antes de asignar plazos. Una estructura inicial distingue cuatro grupos: configuración y cambios de política; aprobaciones y responsables; pruebas o evaluaciones; y datos de tráfico, que pueden contener identificadores, contenido u otros datos personales. La clasificación debe adaptarse a lo que realmente registra cada sistema.

La evidencia de una regla puede conservarse sin guardar el contenido de los mensajes si basta con una referencia, una versión o un resultado agregado. Pero no debe asumirse que la anonimización, la agregación o la eliminación de contenido son siempre posibles sin afectar la investigación: hay que comprobarlo con los procesos y sistemas implicados.

Mantener separadas estas categorías ayuda a evitar que una necesidad de auditoría se convierta automáticamente en una justificación para retener indefinidamente datos de tráfico.

• Política: regla aplicada, versión, ámbito y momento de vigencia, si el sistema los registra.
• Aprobación: decisión, rol aprobador y contexto suficiente para entenderla.
• Prueba: método, condiciones, resultado y limitaciones conocidas.
• Tráfico: campos operativos necesarios para su finalidad, evaluados por separado por su posible sensibilidad.

Crear un inventario útil y limitado

El inventario debe describir datos y procesos reales, no una plantilla teórica. Para cada conjunto, identifica su finalidad, sensibilidad, propietario funcional, sistema de origen, usuarios que necesitan acceso y relación con otras evidencias. Si un campo no tiene un propósito operativo o de cumplimiento documentado, revisa si es necesario recopilarlo o conservarlo.

No hay una fuente técnica en la información disponible que establezca campos obligatorios para reconstruir una decisión de ruta A2P. Por eso, los ejemplos de esta guía son preguntas de diseño, no un estándar ni una obligación normativa.

• ¿Qué decisión o actividad explica este conjunto?
• ¿Cuál es la fuente y cómo se relaciona con la versión de política vigente?
• ¿Incluye contenido, identificadores o datos personales, o puede reducirse a una referencia?
• ¿Quién es responsable de mantenerlo y quién debe poder consultarlo?
• ¿Qué dependencia tiene con exportaciones, informes o sistemas de terceros?

Justificar plazos de conservación, sin asumir uno universal

No existe un plazo universal de conservación de evidencias de enrutamiento A2P SMS que pueda aplicarse sin analizar el contexto. La duración debe justificarse por el uso previsto y contrastarse con las obligaciones legales, regulatorias y contractuales aplicables a las partes y jurisdicciones involucradas. Las fuentes aquí disponibles no permiten fijar un plazo concreto.

Para cada categoría, documenta por qué hace falta conservarla, qué evento inicia o termina la necesidad y quién revisa el plazo. Una regla de política puede tener una necesidad distinta a la de un registro de tráfico. Evita copiar automáticamente la retención general de logs o DLR: esos registros pueden tener finalidades y riesgos diferentes.

Si una disputa, investigación u obligación aplicable exige preservar información, el proceso de conservación debe tener alcance y responsables definidos. La organización debe determinar cómo se relaciona esa preservación con la política habitual y cuándo puede revisarse o levantarse.

• Vincula cada plazo a una finalidad documentada y a las obligaciones verificadas para el caso.
• Distingue el periodo operativo ordinario de cualquier preservación excepcional.
• Revisa los plazos cuando cambien las finalidades, los contratos, la regulación aplicable o los sistemas.
• No presentes una recomendación interna como un requisito legal universal.

Controlar el acceso con permisos definidos

El acceso debe responder a tareas concretas. Como criterio de diseño, asigna permisos por función y concede únicamente lo necesario para administrar políticas, aprobar cambios, analizar incidentes o atender revisiones. La separación entre quien propone un cambio y quien lo aprueba puede ser útil, pero debe ajustarse al tamaño, los riesgos y los controles reales de la organización.

Registra las consultas y modificaciones cuando los sistemas lo permitan y exista una finalidad definida para hacerlo. Esos registros también son datos: inclúyelos en el inventario, limita su acceso y establece para ellos una revisión de conservación. La evidencia disponible no permite afirmar que una plataforma A2P concreta ofrezca estos controles de forma nativa.

• Define roles y acciones permitidas; evita permisos amplios sin justificación.
• Revisa periódicamente cuentas y permisos, especialmente tras cambios de función.
• Evalúa la separación entre propuesta, aprobación y ejecución de cambios.
• Trata los registros de consulta como información que también necesita finalidad y gobierno.

Diseñar un borrado verificable, incluidas copias y exportaciones

Una política de borrado debe especificar qué información se elimina o deja de estar disponible, quién autoriza la operación, cómo se registra su ejecución y cómo se gestionan excepciones de conservación. Antes de borrar, comprueba si hay obligaciones aplicables o una preservación documentada que afecte al conjunto.

El alcance no termina necesariamente en el repositorio principal: revisa exportaciones, informes, almacenamiento secundario y copias de seguridad. No debe prometerse que las copias de seguridad se borran de inmediato; su ciclo y tratamiento dependen de la arquitectura y de los procedimientos de cada organización. Si una copia no puede modificarse de forma selectiva, documenta cómo se controla su acceso y cómo se evita reutilizar datos que deberían dejar de estar disponibles.

La verificación puede basarse en evidencia del proceso —por ejemplo, registro de la solicitud, alcance, ejecución, resultado y excepciones— siempre que la solución técnica permita obtenerla. No afirmes que una marca de borrado equivale a eliminación física de todas las copias sin haber comprobado ese comportamiento.

• Identifica repositorios, exportaciones y copias antes de iniciar el proceso.
• Registra alcance, responsable, fecha, resultado y cualquier excepción.
• Comprueba qué significa técnicamente “borrado” en cada sistema.
• Define cómo se evita restaurar o volver a utilizar información que ya no debe estar disponible.

Responder a una auditoría o disputa con contexto y procedencia

Una respuesta sólida no depende de acumular datos sin límite, sino de poder explicar el origen y el significado de la evidencia disponible. Prepara un procedimiento para localizar la versión de política relevante, relacionarla con la aprobación y las pruebas pertinentes y describir qué datos de tráfico se conservaron, por qué y con qué limitaciones.

Cuando falte información o una fuente no permita confirmar un hecho, decláralo. Por ejemplo, diferencia un estado comunicado por un DLR de una recepción verificada independientemente. Si se entrega información a un auditor o a una contraparte, aplica los permisos y las restricciones contractuales y legales que correspondan; no compartas datos adicionales por comodidad.

• Identifica quién solicita la evidencia, el alcance y la autoridad de la solicitud.
• Reúne versiones, aprobaciones, pruebas y referencias necesarias para explicar la decisión.
• Registra la fuente, el periodo cubierto y las limitaciones de los datos.
• Minimiza la información de tráfico compartida y documenta qué se entrega.

Lista de comprobación para implantar una política revisable

Empieza con un alcance pequeño: identifica los procesos de decisión que quieres poder reconstruir y los sistemas que intervienen. Después valida el inventario con operaciones, seguridad, privacidad y cumplimiento antes de fijar permisos y plazos.

La política debe poder cambiar cuando cambien las necesidades o las obligaciones. Asigna un responsable de revisión y conserva la justificación de los cambios; no conviertas una configuración inicial en una regla permanente sin volver a evaluarla.

• Definir qué decisiones y procesos cubre la política.
• Inventariar datos, fuentes, sensibilidad, finalidad y responsables.
• Separar evidencia de decisión de logs generales, DLR y datos de tráfico.
• Justificar cada plazo con el uso y las obligaciones aplicables, sin imponer uno universal.
• Asignar accesos por función y revisar permisos.
• Documentar conservación excepcional, borrado, copias y exportaciones.
• Preparar una respuesta de auditoría que preserve procedencia y explique limitaciones.
• Fijar una revisión periódica y un responsable de mantener la política.