Una empresa puede tener firewall, autenticación multifactor, copias de respaldo y una larga lista de políticas. Y aun así estar mal preparada para responder una pregunta bastante incómoda: ¿cómo sabemos que nuestros controles están…
Una empresa puede tener firewall, autenticación multifactor, copias de respaldo y una larga lista de políticas. Y aun así estar mal preparada para responder una pregunta bastante incómoda: ¿cómo sabemos que nuestros controles están funcionando de verdad?
Ese es el punto en el que la conversación deja de ser puramente tecnológica y se convierte en una conversación de gestión. No basta con instalar controles. Hay que decidir qué se protege, frente a qué riesgo, quién responde y qué evidencia permite comprobar que la decisión sigue siendo válida.
Un control que existe en el papel puede no existir en la práctica. Y un control que opera hoy puede dejar de ser suficiente mañana.
En mi experiencia auditando sistemas de gestión, esta diferencia aparece una y otra vez. La organización tiene documentos. Tiene herramientas. Incluso puede tener responsables designados. Pero cuando uno sigue el rastro del riesgo hasta la evidencia, aparecen vacíos: accesos que nadie revisa, proveedores que cambiaron, excepciones que quedaron abiertas o controles que dependen de una persona que “siempre se acuerda”.
El SGSI no es una caja de herramientas
ISO/IEC 27001:2022 establece los requisitos de un Sistema de Gestión de Seguridad de la Información, o SGSI. La palabra importante aquí es sistema. Un SGSI no es el inventario de software de ciberseguridad de la empresa. Se parece más al tablero desde el que la organización decide qué riesgos acepta, cuáles trata, quién hace qué y cómo revisa si las medidas siguen siendo adecuadas.
Pensemos en un caso sencillo. La empresa contrata un nuevo proveedor en la nube. Tecnología puede revisar la configuración técnica, pero el riesgo no termina ahí. Compras necesita entender las condiciones del servicio; Legal, las obligaciones contractuales; el dueño del proceso, qué ocurriría si el servicio falla; y Seguridad, qué información se procesa y cómo se protegerá. Si cada área ve solo su pedazo, probablemente nadie esté viendo el riesgo completo.
Por eso la seguridad de la información no pertenece únicamente a TI. Un SGSI efectivo conecta negocio, tecnología, personas y terceros. Y obliga a que ciertas preguntas tengan respuesta antes de que ocurra el incidente, no después.
- ¿Qué información y servicios son realmente críticos para operar?
- ¿Quién puede aceptar un riesgo y quién debe escalarlo?
- ¿Qué terceros tienen acceso o procesan información sensible?
- ¿Qué cambia cuando una persona se va, un sistema se actualiza o un proveedor modifica su servicio?
- ¿Qué evidencia podemos mostrar para demostrar que los controles operaron?
La evidencia cambia la calidad de la conversación
Decir “tenemos un procedimiento de gestión de accesos” describe una intención. Mostrar revisiones periódicas, altas y bajas autorizadas, excepciones aprobadas y acciones tomadas ante desviaciones demuestra que el proceso está operando. No es lo mismo.
La evidencia tampoco tiene que convertirse en una montaña de registros. En la mayoría de los casos, lo importante es que sea suficiente para reconstruir una decisión: qué riesgo se identificó, qué control se seleccionó, quién era responsable, qué ocurrió y qué se hizo cuando algo no salió como se esperaba.
Ahí es donde la auditoría aporta valor. No debería limitarse a verificar que existe un documento. Debería seguir el hilo desde el riesgo hasta la operación del control y preguntar si el resultado es coherente con lo que la organización afirma.
¿Y qué tiene que ver esto con inteligencia artificial?
Mucho. Una organización que ya utiliza IA probablemente está incorporando nuevos proveedores, datos, integraciones, accesos y cambios frecuentes. El SGSI ofrece una base muy útil para controlar parte de esa exposición: seguridad, activos de información, incidentes, terceros, continuidad y gestión de accesos.
Pero no resuelve por sí solo todas las preguntas de gobernanza de IA. La organización también necesita definir para qué se usa el sistema de IA, qué impactos puede generar, qué nivel de supervisión humana requiere, cómo se controla su ciclo de vida y qué ocurre cuando cambia el modelo, el proveedor o el contexto de uso.
ISO/IEC 27001 e ISO/IEC 42001 no deberían convertirse en dos mundos separados. Si ya existe una arquitectura de gestión útil, lo sensato suele ser integrarla.
Eso evita duplicar comités, matrices, auditorías y procedimientos sin necesidad. Además, hace que la gobernanza sea más fácil de operar. Un responsable de negocio no debería tener que aprender tres sistemas paralelos para gestionar el mismo riesgo desde ángulos distintos.
Para muchas organizaciones latinoamericanas, menos duplicación es una ventaja real
No todas las organizaciones de la región tienen grandes equipos de GRC, ciberseguridad, compliance y auditoría interna. Eso obliga a diseñar sistemas proporcionales. Proporcional no significa débil. Significa concentrar el esfuerzo donde el riesgo lo justifica y reutilizar lo que ya funciona.
Si una empresa quiere empezar a fortalecer su SGSI, probablemente sea más útil comenzar por una línea base honesta que por una lista de documentos por crear. ¿Qué información es crítica? ¿Dónde están los riesgos que más preocupan? ¿Qué controles ya existen? ¿Cuáles dejan evidencia? ¿Cuáles dependen demasiado de la memoria de una persona?
Ese diagnóstico suele revelar más que una revisión superficial de políticas. Y, si la empresa ya está incorporando IA, permite construir la seguridad y la gobernanza sobre una misma lógica de gestión.
La seguridad de la información no se demuestra porque existan muchas herramientas. Se demuestra cuando la organización puede explicar sus decisiones, operar sus controles y aprender de la evidencia.
