Con la entrada en vigencia de la Ley 21.719 a la vuelta de la esquina, cumplir ya no será cuestión de prometer buenas prácticas ni acumular políticas en carpetas. Lo que exige la norma es otra cosa: capacidad real para sostener lo que se declara. Y ahí TI se vuelve clave, porque es donde realmente se ejecutan —o se caen— los controles.
Qué significa “evidencia de cumplimiento” en la ley 21.719
En la Ley 21.719, cumplir también implica demostrar capacidad de control con evidencia concreta. Esto queda claro según lo establecido en el artículo 14.5 del documento de ley, que obliga a aplicar medidas técnicas y organizativas adecuadas al riesgo y a probar su existencia y funcionamiento “en caso de controversia judicial o administrativa”.
La evidencia de cumplimiento, entonces, no se limita a un solo documento. Se construye en capas complementarias que, al combinarse, pueden sostener o derribar la defensa de una organización frente a una auditoría o sanción.
Estas capas incluyen:
- Evidencia normativa y documental:
Políticas, contratos, reglamentos internos, nombramiento del DPO (como sugiere el artículo 49) y cualquier documento que respalde lo declarado por la organización.
- Evidencia estructural y de diseño:
Pruebas de cómo se organiza el cumplimiento: matriz de riesgos, modelo de prevención de infracciones (también del art. 49), protocolos internos, canales de reporte, etc.
- Evidencia técnica y operativa:
Todo lo que viene de los sistemas: logs, registros de incidentes, trazabilidad de acciones correctivas, cifrado, respaldos, pruebas de recuperación (según lo exigido en el art. 14 quinquies).
- Evidencia de gestión y mejora continua:
Revisiones, auditorías internas, métricas, planes de mejora, actualizaciones de controles. Es lo que prueba que el cumplimiento no es estático.
El rol de TI en la construcción de evidencia de cumplimiento
TI no es el área dueña del cumplimiento ni debería cargar con toda la responsabilidad legal. Pero sí cumple un rol insustituible: hace posible demostrar que lo declarado se cumple en la práctica. Sistemas, dispositivos y respuestas operativas pasan por sus manos, y si no se registran bien, no existen frente a una auditoría.
En palabras simples, TI no necesita saber de derecho, pero sí debe saber qué evidencias técnicas valen y cómo integrarlas al sistema de cumplimiento.
Aclarar este rol es clave para evitar errores comunes como:
- Confundir ejecución con control legal:
Que TI configure una medida no significa que haya sido evaluada, formalizada ni aprobada como control.
- Crear puntos ciegos de cumplimiento:
Sin trazabilidad técnica, un incidente bien resuelto puede parecer negligencia ante la Agencia.
- Perder foco en lo que importa::
Cuando se sobrecarga a TI con tareas legales, se pierde tiempo operativo valioso… y no se mejora el cumplimiento.
- Romper la colaboración entre áreas:
Pensar que “TI se encarga” genera desconexión entre lo técnico, lo legal y lo organizacional, debilitando todo el modelo de cumplimiento.
Tipos de evidencia técnica que sí aportan al cumplimiento
No toda acción técnica es automáticamente evidencia útil. Para que tenga peso frente a una fiscalización o un incidente, debe hablar el idioma del riesgo y estar conectada con un control definido. La Ley 21.719 no exige perfección, pero sí pruebas defendibles de que se hicieron cosas concretas. Estas son las señales técnicas que sí aportan al cumplimiento:
Evidencia de control
Este tipo de evidencia muestra que la organización tiene visibilidad sobre sus activos y sistemas. No se trata solo de “tener cosas”, sino de saber exactamente qué existe, dónde está, quién lo usa y cómo está protegido.
- Inventario actualizado de dispositivos, sistemas y aplicaciones.
- Registro de ubicación y estado de los activos críticos.
- Control de accesos: quién entra, desde dónde, con qué nivel de permiso, tipos de contraseña.
- Pruebas de que los dispositivos tienen políticas de seguridad activas (antivirus, firewall, MDM, VPN, encriptación, etc).
- Alertas o reportes que evidencien cambios o brechas en el control.
Evidencia de acción
Esta evidencia demuestra que la organización no solo tiene controles, sino que los aplica cuando ocurre algo. Si hubo un incidente o una pérdida, ¿se hizo algo? ¿cuándo? ¿quedó registro?
- Logs de ejecución de acciones como bloqueo remoto, borrado o revocación de acceso.
- Tiempos de respuesta frente a incidentes, desde detección hasta contención.
- Reportes de restauración de respaldos tras caídas o filtraciones.
- Bitácoras de rotación de contraseñas o credenciales comprometidas.
- Pruebas de que se activaron los protocolos definidos (por ejemplo, en el plan de respuesta a incidentes).
Evidencia de consistencia
Demostrar que una acción se ejecutó una vez no alcanza. Esta evidencia prueba que las acciones no fueron excepcionales, sino parte de una práctica repetible, estable y alineada con lo que la organización declaró en sus políticas.
- Automatizaciones o tareas programadas que se ejecutan periódicamente (scans, backups, reportes).
- Logs de cumplimiento recurrente: ejemplo, revisiones semanales de estado de dispositivos.
- Reportes que muestran tendencias o patrones, no solo eventos aislados.
- Auditorías técnicas o revisiones de controles con frecuencia definida.
- Coincidencia entre lo que dicen las políticas y lo que muestran los registros.
No todo lo que suena técnico sirve como evidencia. De hecho, muchas organizaciones caen en la trampa de creer que tienen el cumplimiento resuelto, cuando en realidad solo acumulan pantallazos, herramientas mal configuradas o logs que nadie revisa. Esta sección expone los errores más comunes que generan una falsa sensación de control… y que podrían costar caro.
Modelo de evidencia de cumplimiento ley 21.719
Conoce si tu organización puede demostrar cumplimiento con la Ley ante una fiscalización. Evalúa tu modelo por componente y detecta brechas críticas.
Descargar Checklist
Checklist de Cumplimiento – Ley de protección de datos (21.719)
¿Quieres empezar con una hoja de ruta clara? Prepara a tu organización para cumplir con las nuevas exigencias regulatorias.
Descargar Checklist
Qué no es evidencia técnica válida (errores frecuentes)
No todo lo que suena técnico sirve como evidencia. De hecho, muchas organizaciones caen en la trampa de pensar que tienen el cumplimiento resuelto, cuando en realidad solo acumulan pantallazos, herramientas mal configuradas o logs que nadie revisa. Esta sección expone los errores más comunes que generan una falsa sensación de control… y que podrían costar caro.
- Screenshots sin contexto, fecha o trazabilidad: Un pantallazo aislado puede servir para explicar algo internamente, pero no tiene valor regulatorio real. Sin fecha, sin origen claro y sin relación con un control definido, es imposible usarlo como prueba defendible ante una fiscalización.
- Logs masivos sin interpretación ni relación con riesgos: Tener miles de registros no equivale a tener evidencia. Cuando los logs no están explicados, filtrados o conectados a un riesgo específico, se vuelven ruido técnico sin valor de cumplimiento.
- Acciones no registradas (“se hizo, pero no quedó evidencia”): Uno de los errores más comunes: se actuó correctamente, pero nadie lo dejó registrado. Frente a la ley, una acción sin trazabilidad simplemente no existe.
- Confundir “tener una herramienta” con “demostrar control”: Contar con una herramienta de seguridad no prueba cumplimiento por sí sola. Lo que importa no es la licencia, sino cómo se usa, cuándo se activa y qué evidencia genera.
- Evidencia aislada que no conversa con otros artefactos de compliance: La evidencia técnica no puede vivir sola. Si no se conecta con políticas, riesgos o protocolos, pierde fuerza regulatoria y se vuelve frágil ante cualquier revisión.
Cómo la evidencia técnica se conecta con otros artefactos de cumplimiento
La evidencia técnica, por sí sola, no basta para cumplir con la ley 21719. Para que tenga peso real en una auditoría o investigación, debe estar conectada con el sistema de cumplimiento: controles definidos en la Matriz de Aplicabilidad (Matriz SoA), riesgos priorizados, protocolos escritos. Si TI bloquea un equipo perdido, pero esa acción no aparece en el plan de respuesta a incidentes, la defensa se debilita.
TI genera insumos valiosos para compliance, legal y auditoría, pero su valor depende de cómo se integren. La evidencia técnica valida que los controles declarados existen y funcionan, que los riesgos están siendo gestionados, y que los incidentes se abordan según lo planificado. Sin esa conexión, los registros técnicos quedan sueltos, pierden fuerza regulatoria y pueden ser ignorados en una fiscalización.
Dispositivos: el punto crítico de la evidencia hoy
En muchas organizaciones, los dispositivos son el gran punto ciego del cumplimiento. Aunque almacenan y procesan datos personales a diario, no siempre se incluyen en los controles ni en los reportes. La Ley 21.719 no distingue si los datos están en un servidor o en un celular: lo importante es protegerlos… y demostrarlo con evidencia.
¿Por qué los dispositivos deben estar integrados al sistema de cumplimiento?
- Porque ahí viven los datos personales más expuestos:
Correos, documentos, bases de datos locales, accesos remotos: todo pasa por laptops y móviles. Ignorarlos es dejar desprotegido lo más sensible.
- Porque son los activos más fáciles de perder o robar:
A diferencia de un servidor en rack, un notebook viaja, se olvida, se cae del bolso o se queda en un taxi. Los riesgos físicos son reales y frecuentes.
- Porque generan evidencia clave en incidentes:
Logs de acceso, geolocalización, borrado remoto, alertas de salida de perímetro: todo eso puede respaldar una respuesta efectiva si está bien configurado.
- Porque permiten validar controles técnicos en tiempo real:
Políticas de cifrado, bloqueo automático, MDM activo, control de usuarios… todo se puede probar y auditar con dispositivos bien gestionados.
- Porque son el puente entre el usuario y los datos:
No importa qué tan robusto sea el sistema central: si el endpoint no está bajo control, la fuga de información sigue siendo probable.
Límites claros: hasta dónde llega la evidencia técnica
La evidencia técnica es clave, pero no lo es todo. Pensar que con logs, backups y herramientas se cumple la ley es una ilusión peligrosa. Hay decisiones que no nacen en TI: la definición de políticas, el análisis legal o la gobernanza general no se pueden automatizar ni registrar con un script.
TI no debe cargar con promesas de “cumplimiento total”. Su verdadero aporte está en:
- Reducir brechas: cerrar puntos ciegos operativos que pueden generar riesgos.
- Sostener lo declarado: dar respaldo técnico a lo que se firma en una política o procedimiento.
- Demostrar diligencia razonable: probar que se actuó con criterio, se hicieron esfuerzos y se dejaron registros útiles.
Conclusión: Sin evidencia técnica, el cumplimiento no se sostiene
La Ley 21.719 no solo castiga la falta de papeles, sino también la falta de control demostrable. Y ese control se ve, o no, en los sistemas. TI es el punto en el que el cumplimiento se concreta o se cae. Puedes tener una política impecable, pero si no puedes probar que se aplicó, frente a la Agencia eso no vale nada.
Construir evidencia técnica no es un proyecto paralelo, ni una carga extra. Es parte de hacer las cosas bien: ordenar lo que ya existe, registrar lo que antes quedaba suelto, y conectar la operación con el modelo de cumplimiento. Porque hoy, hacer bien las cosas no basta, pues hay que poder demostrarlo, con trazabilidad, con contexto y con intención clara.
Si necesitas una herramienta que te permita ver, registrar y demostrar lo que pasa con tus dispositivos, con evidencias listas ante cualquier auditoría, contáctanos en Prey.
