Hasta hace poco, la seguridad de la información era sobre todo un compromiso con los clientes. Se hacía bien o se hacía mal, y quien lo medía era el propio cliente cuando auditaba a su proveedor.
Eso cambió. Hoy la seguridad de la información tiene peso jurídico propio y fiscalizadores con nombre, y eso convierte el trabajo diario del área de TI en algo distinto: en prueba.
Tres leyes que convergen en lo mismo
No es una norma nueva, son tres cuerpos legales que llegaron por caminos distintos y terminan pidiendo lo mismo.
- La Ley 21.719 de protección de datos personales. Crea la Agencia de Protección de Datos Personales, con facultades para fiscalizar y sancionar. Su entrada en vigencia está fijada para el 1 de diciembre de 2026, y hay un proyecto en tramitación para postergarla un año.
- La Ley 21.663, marco de ciberseguridad. Hace algo equivalente a través de la Agencia Nacional de Ciberseguridad, para las empresas que alcanza.
- La responsabilidad penal de la empresa. Los delitos informáticos de la Ley 21.459 se incorporaron al catálogo de la Ley 20.393, la de responsabilidad penal de las personas jurídicas, que después fue reformada por la Ley 21.595 de delitos económicos, con más exigencia sobre los modelos de prevención y sanciones más duras.
Ese tercer punto es el que menos se tiene en el radar, y es el más fuerte. En simple: un ciberdelito cometido desde o a través de tu empresa puede hacer responsable penalmente a la empresa, no solo a la persona que lo hizo. Y la defensa es haber tenido un modelo de prevención que estuviera operando de verdad.
El incumplimiento además tiene precio. Las dos primeras leyes usan la misma escala base: hasta 5.000 UTM las infracciones leves, hasta 10.000 las graves y hasta 20.000 las gravísimas. En la Ley 21.719, la reincidencia de una empresa que no sea de menor tamaño puede llegar al 4% de los ingresos anuales por ventas y servicios.
La consecuencia práctica es una sola
Ya no basta con hacer las cosas bien. Hay que poder demostrarlo.
Ante un fiscalizador, lo que no dejó registro no ocurrió. La revisión de accesos que se hizo conversando, la capacitación que se dio en una reunión, el incidente que se resolvió por teléfono: todo eso pasó de verdad, y nada de eso sirve como prueba.
Es un cambio incómodo porque no se trata de trabajar más, sino de dejar rastro de lo que ya se hace. Y el rastro hay que dejarlo en el momento, no después.
Lo que hace TI todos los días, y en qué se convirtió
Esta es la lista concreta. A la izquierda, la tarea de siempre. A la derecha, lo que hay que poder mostrar.
- Configuraciones y cambios en los sistemas. Quién lo hizo, cuándo, qué cambió y quién lo autorizó. Un cambio sin autorización registrada es un hallazgo, aunque haya sido el cambio correcto.
- Respaldos. Que existan no basta. Lo que se pide es evidencia de la última restauración probada: fecha, qué se restauró y si resultó. Un respaldo que nunca se probó no demuestra disponibilidad.
- Doble factor de autenticación. Sobre qué sistemas, para qué usuarios y desde cuándo. Y, sobre todo, las excepciones: quién no lo tiene, por qué y quién aprobó esa excepción.
- Gestión de claves y de accesos. La política importa menos que la evidencia de la revisión periódica: fecha, quién la hizo, qué se encontró y qué se corrigió.
- Baja de usuarios. Acá hay dos fechas que tienen que coincidir: la salida de la persona y la revocación de sus accesos. Cuando no coinciden, el hallazgo se escribe solo.
- Tratamiento y análisis de datos. Qué datos personales se usan, para qué finalidad y con qué base de licitud. Esta es la que más cuesta, porque TI suele saber dónde están los datos pero no con qué permiso se usan.
- Incidentes. El registro, incluso cuando no pasó nada grave. Si en todo el período no hay ningún incidente registrado, eso también es un hallazgo: significa que el canal no se está usando.
- Proveedores con acceso a tus sistemas. El acuerdo firmado con cláusulas de seguridad y la evidencia de que se los volvió a evaluar después de contratarlos.
El error que más se repite
No es hacer las cosas mal. Es hacerlas bien y no registrarlas.
Las áreas de TI suelen tener buenas prácticas instaladas por oficio: se revisan accesos, se prueban respaldos, se dan de baja usuarios. Lo que falta casi siempre es la constancia, porque históricamente a nadie se la pidieron. Eso es exactamente lo que cambia cuando aparece un fiscalizador con facultades para multar.
Dónde entra ISO 27001
La norma no pide nada que estas leyes no vayan a pedir igual. Lo que hace es ordenarlo: define quién es responsable de cada control, con qué frecuencia se revisa y qué evidencia queda. El resultado es que el expediente se arma solo, como parte del trabajo, en vez de tener que reconstruirlo cuando llega la fiscalización.
Y la auditoría interna es la que verifica que eso esté ocurriendo de verdad, antes de que lo verifique alguien de afuera. Es la diferencia entre descubrir una brecha de evidencia en una auditoría propia, donde corregirla es barato, y descubrirla en una fiscalización, donde ya no lo es.
Si tu empresa ya tiene un modelo de prevención de delitos, hay un punto adicional: ese modelo y tu sistema de seguridad de la información tienen que poder mostrarse juntos y no contradecirse. Son dos expedientes que hoy se leen en conjunto.
