En muchas organizaciones, el RAT vive en el mundo de compliance y la seguridad de la información vive en el mundo de TI. Son dos equipos distintos, con herramientas distintas, que rara vez se sientan juntos a trabajar. El resultado es un Registro de Actividades de Tratamiento que declara medidas de seguridad que nadie verifica, y un SGSI que protege activos sin saber cuáles contienen datos personales.
Esa desconexión es un problema real bajo la Ley 21.719. La ley exige que las medidas de seguridad sean proporcionales al riesgo del tratamiento y, lo más importante, demostrables. No basta con tener un RAT que diga "cifrado" en la columna de medidas y una política ISO 27001 que diga "aplicamos cifrado". La Agencia de Protección de Datos Personales va a preguntar: en qué dispositivos, con qué estándar, desde cuándo, y cómo lo verifican.
Este artículo explica cómo conectar ambos mundos de forma operativa: qué controles ISO 27001 alimentan directamente al RAT, cómo el inventario de activos se convierte en insumo legal, y por qué la respuesta ante incidentes depende de que esa conexión funcione antes de que algo salga mal.
Por qué el RAT y el SGSI no pueden vivir separados
El RAT documenta qué datos personales trata la organización, con qué finalidad, bajo qué base legal y con qué medidas de protección. El Sistema de Gestión de Seguridad de la Información (SGSI), por su lado, define controles técnicos y organizativos para proteger la información. En teoría, deberían alimentarse mutuamente. En la práctica, casi nunca lo hacen.
El problema tiene una raíz organizacional. El RAT lo construye el DPO o el equipo legal a partir de entrevistas y formularios. El SGSI lo gestiona el equipo de TI o el CISO con base en evaluaciones de riesgo técnicas. Cada uno produce documentación que el otro no lee. Y cuando la Agencia pide demostrar que las medidas de seguridad declaradas en el RAT son reales, nadie puede conectar los puntos.
La Ley 21.719 no menciona ISO 27001 de forma explícita, pero su artículo 14 quinquies exige medidas técnicas y organizativas apropiadas para garantizar la seguridad de los datos. Si tu organización ya tiene un SGSI certificado o en proceso, tienes entre un 50% y 60% de los requisitos de seguridad cubiertos. El problema es que ese avance solo cuenta si puedes demostrar cómo cada control del SGSI protege los tratamientos documentados en tu RAT.
Para organizaciones que también operan bajo la Ley 21.663 de Ciberseguridad, la integración es aún más crítica: ambas leyes convergen en exigir controles verificables, respuesta ante incidentes documentada y evidencia auditable.
El inventario de activos como punto de partida
Toda conexión entre RAT y seguridad de la información empieza por la misma pregunta: en qué activos viven los datos personales que documentaste en tu registro.
ISO 27001 exige un inventario de activos de información (control A.5.9) que identifique hardware, software, personas y documentación asociados a la gestión de la información. La gestión de inventario de activos según ISO 27001 ya detalla cómo implementar este control. Lo que falta en la mayoría de las organizaciones es cruzar ese inventario con el RAT.
El cruce funciona así: cada tratamiento documentado en el RAT debería poder responder "en qué sistema o dispositivo se ejecuta este tratamiento". Y cada activo del inventario ISO 27001 que procese datos personales debería tener una referencia al tratamiento correspondiente en el RAT.
Cuando ese cruce no existe, aparecen dos problemas:
- Activos que procesan datos personales pero no aparecen en el RAT (los "tratamientos fantasma" que cubrimos en nuestra guía sobre errores comunes del RAT)
- Tratamientos del RAT que declaran medidas de seguridad sobre activos que nadie tiene inventariados
El inventario de activos no es un ejercicio separado del RAT. Es su complemento técnico. Y en el contexto de la Ley 21.719, ese complemento es lo que transforma declaraciones de seguridad en evidencia verificable.
Clasificación de datos: lo que conecta riesgo con controles
El RAT documenta categorías de datos personales por tratamiento: datos de identificación, datos laborales, datos sensibles, datos financieros. Pero esa categorización, por sí sola, no define qué nivel de protección necesita cada conjunto de datos. Ahí entra la clasificación de datos.
La clasificación asigna un nivel de sensibilidad (alto, medio, bajo) que determina qué controles técnicos aplican. Un tratamiento que involucra datos de salud ocupacional necesita controles más estrictos que uno que maneja correos electrónicos de contacto comercial. Esa diferenciación es exactamente lo que la Ley 21.719 exige cuando habla de medidas "proporcionales al riesgo".
En la práctica, la conexión funciona en tres pasos:
- El RAT identifica qué categorías de datos se tratan en cada proceso
- La clasificación de datos asigna un nivel de sensibilidad a cada categoría
- El SGSI define controles específicos según ese nivel de sensibilidad
Sin clasificación, todos los datos reciben el mismo tratamiento de seguridad. Eso genera dos riesgos: sobreproteger datos de bajo riesgo (ineficiencia) o subproteger datos sensibles (exposición legal). Ambos son problemas reales en fiscalizaciones, porque la Agencia va a evaluar si la proporcionalidad tiene sentido.
Mapeo de controles ISO 27001 al RAT
Esta es la parte que casi nadie hace y que más valor operativo tiene. Mapear controles ISO 27001 específicos a los campos del RAT permite demostrar, control por control, cómo la organización protege cada tratamiento de datos personales.
Los controles más relevantes del Anexo A de ISO 27001:2022 para el RAT son:
Control de acceso (A.5.15 - A.5.18)
Quién puede acceder a los datos de cada tratamiento, bajo qué criterio y con qué nivel de privilegio. El RAT debe poder responder "quién accede" y el SGSI debe demostrar que ese acceso está restringido al mínimo necesario.
Aplicación práctica: si tu RAT documenta un tratamiento de nómina, el SGSI debe demostrar que solo el equipo de RRHH y finanzas tiene acceso a esos datos, con autenticación reforzada y registro de accesos.
Gestión de activos (A.5.9 - A.5.14)
Inventario, clasificación, etiquetado y manejo de activos que procesan datos personales. Este bloque de controles alimenta directamente la columna de "medidas de seguridad" del RAT.
Aplicación práctica: cada laptop que procesa datos sensibles debe estar inventariada, con su nivel de clasificación, su responsable asignado y su estado de cifrado documentado.
Cifrado (A.8.24)
Política de cifrado aplicada a datos en tránsito y en reposo. El RAT declara "cifrado" como medida; el SGSI debe especificar qué estándar (AES-256, BitLocker, FileVault), en qué dispositivos y con qué verificación.
Aplicación práctica: no basta con una política que diga "todos los discos deben estar cifrados". Se necesita un mecanismo que confirme, dispositivo por dispositivo, que el cifrado está activo en este momento.
Gestión de incidentes de seguridad (A.5.24 - A.5.28)
Detección, evaluación, respuesta y aprendizaje ante incidentes. Este bloque conecta directamente con la obligación de notificación de brechas de la Ley 21.719 (72 horas desde el conocimiento del incidente).
Aplicación práctica: si un dispositivo con datos personales se pierde, el SGSI debe tener un procedimiento que identifique qué tratamientos del RAT están afectados, qué datos contenía el equipo y qué acciones de mitigación se ejecutaron.
Registro y monitoreo (A.8.15 - A.8.16)
Logs de actividad, monitoreo de eventos y protección de registros. Estos controles generan la evidencia que demuestra que los controles declarados en el RAT funcionan en la práctica.
Aplicación práctica: los logs de acceso a sistemas que procesan datos personales deben ser inalterables, estar disponibles para exportación y cubrir un período suficiente para responder solicitudes de la Agencia.
Respuesta ante incidentes: donde el RAT se pone a prueba
El momento en que la conexión entre RAT y seguridad de la información se vuelve crítica es cuando ocurre un incidente. Un robo de laptop, una brecha de datos, un acceso no autorizado. En ese momento, la organización tiene 72 horas para notificar a la Agencia y necesita responder preguntas muy concretas:
- Qué datos personales estaban en el dispositivo o sistema afectado
- Qué tratamientos del RAT están comprometidos
- Qué medidas de seguridad estaban activas al momento del incidente
- Qué acciones de mitigación se ejecutaron y cuándo
Si el RAT no está conectado con el inventario de activos y el SGSI, responder esas preguntas toma días. Y 72 horas no dan margen para improvisar.
Un plan de respuesta ante incidentes efectivo necesita poder cruzar tres fuentes de información en minutos:
- El RAT: para identificar qué tratamientos y qué categorías de datos están afectados
- El inventario de activos: para confirmar qué dispositivo, qué usuario y qué estado de seguridad tenía
- Los logs del SGSI: para documentar acciones de mitigación con marca de tiempo
Sin ese cruce, el reporte de incidente que llega al DPO es incompleto, y la notificación a la Agencia se basa en suposiciones en lugar de evidencia. Eso no solo genera riesgo regulatorio; puede ser interpretado como falta de diligencia, lo que agrava las sanciones.
El rol de la gestión de endpoints en esta conexión
La gestión de endpoints es el eslabón operativo que conecta lo que el RAT declara con lo que el SGSI puede demostrar. Sin visibilidad en tiempo real sobre los dispositivos que procesan datos personales, la conexión entre ambos mundos es teórica.
Prey cubre exactamente esa capa para equipos de TI que necesitan evidencia operativa:
- Inventario automatizado: cada dispositivo registrado con su sistema operativo, usuario asignado, última conexión y ubicación. Eso alimenta tanto el inventario de activos ISO 27001 como la columna de medidas del RAT.
- Estado de cifrado verificable: confirmación en tiempo real de BitLocker o FileVault por dispositivo. No una política que dice "deberían estar cifrados", sino un registro que dice "este equipo tiene cifrado activo desde esta fecha".
- Respuesta remota ante incidentes: bloqueo, borrado y factory reset con registros de auditoría inalterables. Cuando el RAT dice "capacidad de borrado remoto" como medida de seguridad, Prey es la herramienta que lo ejecuta y lo documenta.
- Geofencing para control territorial: alertas cuando un dispositivo sale de zonas autorizadas. Relevante cuando el RAT documenta tratamientos que no deben salir del territorio nacional, conectando directamente con el control de transferencias internacionales.
- Logs de auditoría exportables: cada acción sobre cada dispositivo queda registrada con marca de tiempo, usuario y resultado. Eso es exactamente lo que ISO 27001 exige en A.8.15 y lo que la Agencia espera ver como evidencia.
La diferencia entre una organización que conecta su RAT con la seguridad de la información y una que no, no está en la cantidad de documentos que produce. Está en la capacidad de responder, en minutos, preguntas que la Agencia va a hacer sobre dispositivos específicos que procesan datos personales.
Si estás integrando tu RAT con tu SGSI y necesitas cubrir la capa de endpoints, agenda una demo para ver cómo Prey cierra esa brecha.
Preguntas frecuentes
Qué relación tiene el RAT con ISO 27001?
El RAT documenta qué datos personales se tratan y con qué medidas de seguridad. ISO 27001 define los controles técnicos y organizativos que implementan esas medidas. La conexión entre ambos permite demostrar que las medidas declaradas en el RAT son reales, verificables y proporcionales al riesgo de cada tratamiento.
Si mi organización ya tiene ISO 27001, necesita un RAT?
Sí. ISO 27001 cubre seguridad de la información en general, pero no reemplaza las obligaciones específicas de protección de datos personales bajo la Ley 21.719. El RAT documenta finalidades, bases legales, transferencias y plazos de conservación que ISO 27001 no exige. Lo que sí ganas es que los controles del SGSI ya cubren entre un 50-60% de las medidas de seguridad que el RAT necesita declarar.
Qué controles ISO 27001 son más relevantes para el RAT?
Los más directos son: gestión de activos (A.5.9-A.5.14) para inventariar dónde viven los datos, control de acceso (A.5.15-A.5.18) para documentar quién accede, cifrado (A.8.24) para proteger datos en reposo y tránsito, gestión de incidentes (A.5.24-A.5.28) para responder a brechas, y registro/monitoreo (A.8.15-A.8.16) para generar evidencia auditable.
Cómo ayuda esta conexión ante una fiscalización de la Agencia?
Cuando la Agencia revisa tu RAT, puede pedir evidencia de que las medidas de seguridad declaradas están implementadas. Si tu RAT está conectado con el SGSI, puedes exportar evidencia de controles activos (cifrado, accesos, logs) en horas en lugar de días. Eso demuestra diligencia y reduce el riesgo de que una fiscalización derive en sanción.
Cada cuánto debería actualizarse esta conexión RAT-SGSI?
Al menos cada vez que se actualice el RAT (trimestral) o el SGSI (ciclo de auditoría interna). También ante cambios relevantes: nuevo proveedor tecnológico, nuevo tratamiento de datos, incidente de seguridad, o cambio en la clasificación de datos. La conexión debe ser parte del ciclo PDCA del SGSI, no un ejercicio puntual.
Qué pasa si mi RAT declara medidas que el SGSI no puede demostrar?
Esa brecha entre lo declarado y lo implementado es un riesgo regulatorio directo. Si la Agencia detecta que tu RAT dice "cifrado en todos los dispositivos" pero no puedes demostrarlo, puede calificarlo como medida insuficiente o falta de diligencia. La recomendación es auditar esa consistencia antes de que la Agencia lo haga.
