Proteger la información de una organización no termina en las fronteras internas: cada proveedor contratado y cada incidente que se presente ponen a prueba la solidez del sistema de gestión. Los últimos grupos de controles del anexo A de la ISO 27001 abordan precisamente estos dos frentes críticos, y comprenderlos marca la diferencia entre una postura reactiva y una verdaderamente resiliente.
¿Qué exige la ISO 27001 en la relación con proveedores?
El estándar dedica un grupo de cinco controles centrados en la gestión de proveedores. El punto de partida, como ocurre en otros dominios de la norma, es establecer una política de seguridad de la información para proveedores [01:00]. Esta política fija la línea base de contratación: define los requisitos de seguridad que toda relación comercial debe cumplir, sin importar si el proveedor ofrece un componente tecnológico o cualquier otro servicio.
¿Cómo evaluar la seguridad de un proveedor antes de contratarlo?
Antes de firmar un contrato es necesario aplicar una lista de chequeo de seguridad [02:04]. La norma pide verificar la procedencia del proveedor y realizar validaciones de SARLAFT (sistema de administración del riesgo de lavado de activos y financiación del terrorismo). Esto incluye:
- Consultar listas restrictivas como la OFAC, la lista Clinton y la BOE.
- Descartar vínculos con narcotráfico u otras actividades ilícitas.
- Mitigar el riesgo reputacional y el riesgo de contagio, que aparece cuando un proveedor resulta involucrado en procesos de lavado de activos y la compañía queda asociada.
¿Por qué es vital diversificar la cadena de suministro tecnológico?
Uno de los controles más prácticos se refiere a la cadena de suministro a nivel de tecnología [03:17]. La recomendación es clara: no depender de un solo proveedor para servicios críticos. El ejemplo clásico son los enlaces de comunicaciones entre sucursales o con la casa matriz. Lo ideal es contratar dos proveedores independientes con enlaces redundantes en configuración activo-activo, de modo que si uno falla, el otro mantenga la operación.
Además, la norma exige un control de revisión de contratos [04:17]. Si el acuerdo de nivel de servicio establece una disponibilidad del 99,9 % mensual, debe verificarse periódicamente que se cumpla. Aquí surge un matiz importante: el responsable del SGSI da los lineamientos y realiza revisiones aleatorias, pero el dueño del riesgo —la primera línea de defensa, por ejemplo el área de tecnología— es quien ejecuta las revisiones de forma constante [04:46].
Cuando se producen cambios contractuales, como un otrosí o la tercerización de algún componente del servicio, la gestión de cambios con el proveedor obliga a que cada modificación pase por el mismo flujo definido en la política original [05:53].
¿Cómo gestionar incidentes de seguridad de la información?
Ninguna infraestructura es invulnerable. La norma parte de esa premisa y establece controles para que la organización esté preparada ante ataques [06:27].
- Responsabilidades y procedimientos: documentar quién contiene el incidente en primera línea, quién lo soluciona y quién lo registra [06:43].
- Notificación de eventos: cualquier área —no solo tecnología— debe reportar al responsable de seguridad lo que detecte. Si el área de contabilidad identifica un comportamiento anómalo antes que las herramientas técnicas, debe dar la alerta de forma oportuna [07:10].
- Notificación de puntos débiles: las vulnerabilidades no deben ocultarse; se identifican, se comunican al área de tecnología y se corrigen antes de que un atacante las aproveche [07:55].
¿Qué papel cumple el comité de crisis?
El control de evaluación y decisión sobre eventos de seguridad recomienda instalar un comité de crisis [08:27] proporcional al tamaño de la organización. Este comité no debe limitarse al equipo técnico: involucra áreas operativas, contabilidad e incluso dirección, para que las decisiones de contención consideren tanto la perspectiva de negocio como la técnica.
¿Qué ocurre después de controlar un incidente?
Una vez contenido, el foco se traslada a la respuesta: definir qué herramientas utilizar, si las existentes siguen siendo funcionales o si se requieren nuevas [09:08]. Luego viene lo más valioso: las lecciones aprendidas [09:33]. El mismo comité se reúne, recopila todas las evidencias, identifica la causa raíz y diseña controles que ataquen ese origen. El objetivo es que el incidente controlado no vuelva a ocurrir.
Recuerda que el cien por ciento de seguridad no existe [10:14]. Lo que sí existe es la capacidad de prepararse, responder con eficiencia y aprender de cada evento. Si ya aplicas alguno de estos controles en tu organización, comparte tu experiencia y cuéntanos qué retos has encontrado en el camino.
