Organizar ciberseguridad: centralizada, federada o por producto

Cuando una organización discute cómo organizar la ciberseguridad, la conversación suele empezar por el organigrama: a quién reporta el CISO, cuántas personas tiene, si depende de Tecnología o de Riesgo. Son preguntas válidas, pero llegan tarde. Antes conviene responder otra: dónde se toman las decisiones de seguridad del día a día y quién responde por ellas.

No existe una estructura correcta para todas las organizaciones. Existen tres modelos de referencia, cada uno con ventajas y riesgos conocidos, y una regla que aplica a los tres: hay funciones que se centralizan siempre, sin importar cuánto se distribuya el resto. Este artículo recorre los modelos, propone qué centralizar y qué distribuir, y muestra cómo apoyarse en NIST CSF 2.0 y en el marco NICE para asignar roles sin ambigüedad.

Por qué la estructura importa

La estructura define tres cosas que luego son difíciles de cambiar: la velocidad con que se resuelve una consulta de seguridad, la coherencia de los criterios entre equipos y la claridad de quién rinde cuentas cuando algo falla. Una estructura que no encaja con la forma en que la organización entrega tecnología produce síntomas reconocibles: colas de revisiones que frenan los proyectos, excepciones que nadie registra, equipos de desarrollo que ven a seguridad como un trámite y equipos de seguridad que trabajan siempre al límite.

Este último punto no es menor. Un equipo central que concentra todas las revisiones, todas las alertas y todas las consultas acaba agotado, y el agotamiento es un riesgo operativo en sí mismo. Lo tratamos en detalle en el agotamiento en los equipos de seguridad.

Tres modelos de organización

Los tres modelos se diferencian por dónde está el personal de seguridad y a quién reporta. El diagrama los resume.

Centralizado

Un solo equipo, bajo el CISO, ejecuta o aprueba todas las actividades de seguridad: políticas, gestión de vulnerabilidades, revisiones de arquitectura, monitoreo y respuesta. La ventaja es la coherencia: un criterio, una herramienta, un registro de riesgos. El riesgo es el cuello de botella. Cuando el número de equipos de desarrollo crece, el equipo central se convierte en una cola y la seguridad empieza a percibirse como un freno.

Conviene en organizaciones medianas, con pocos equipos de entrega, una sola jurisdicción o una regulación que exige trazabilidad estricta de cada decisión.

Federado

Un equipo central pequeño define la política, el marco de riesgo y los estándares, y cada unidad de negocio, filial o país tiene su propio equipo de seguridad. Ese equipo reporta en línea jerárquica a su unidad y en línea funcional al CISO. La ventaja es la cercanía al negocio y a la regulación local, algo relevante para grupos que operan en varios países de Latinoamérica o entre Latinoamérica y España. El riesgo son los criterios dispares: si la línea funcional es débil, cada unidad interpreta la política a su manera.

Conviene en grupos con filiales, marcos regulatorios distintos por país o unidades con autonomía presupuestaria.

Por producto

La seguridad se integra en los equipos de producto. Cada equipo asume la seguridad de lo que construye y opera, con apoyo de champions y de especialistas que rotan entre equipos. El centro define guías, mantiene una plataforma de seguridad común (análisis de código, gestión de secretos, plantillas seguras) y conserva las funciones que no se distribuyen. La ventaja es que la seguridad entra en el flujo de entrega en lugar de revisarse al final. El riesgo es diluir la responsabilidad: si todos son responsables y nadie rinde cuentas, los riesgos transversales quedan sin dueño.

Conviene en organizaciones que ya trabajan con equipos de producto estables y una plataforma interna. Si ese es tu caso, este modelo se apoya en lo que describimos en el modelo operativo de producto y en platform engineering.

Comparación de los tres modelos

La tabla resume los criterios que más pesan al elegir. Ningún modelo gana en todas las filas.

Criterio	Centralizado	Federado	Por producto
Coherencia de criterios	Alta	Media; depende de la línea funcional	Media; depende de guías y plataforma
Velocidad de respuesta a los equipos	Baja cuando crece la demanda	Media	Alta
Adaptación a regulación local	Baja	Alta	Media
Costo de coordinación	Bajo	Alto	Medio
Riesgo principal	Cuello de botella y agotamiento	Criterios dispares entre unidades	Responsabilidad diluida
Requisito previo	Presupuesto central suficiente	Política y métricas comunes	Equipos de producto estables y plataforma interna

En la práctica, muchas organizaciones combinan modelos: federado entre países y por producto dentro de la unidad digital, por ejemplo. Combinar está bien, siempre que el reparto de funciones esté escrito.

Qué se centraliza siempre y qué se distribuye

Elijas el modelo que elijas, hay cuatro funciones que recomendamos mantener en el centro, porque su valor depende de que exista una sola versión:

• Política y estándares. Una política de seguridad, un conjunto de estándares y un proceso único de excepciones. Las unidades pueden detallar procedimientos, no reescribir la política.
• Gestión del riesgo. Un registro de riesgos, una metodología de evaluación y un apetito de riesgo aprobado por la dirección. Sin esto no se puede reportar al directorio una visión consolidada.
• Respuesta a incidentes. Un plan, una cadena de escalamiento y una coordinación única para incidentes graves. Los equipos locales ejecutan, pero un incidente que cruza unidades no puede tener dos comandantes.
• Arquitectura de referencia. Patrones aprobados de identidad, cifrado, segmentación y registro. Es lo que permite que los equipos distribuidos tomen decisiones rápidas sin reinventar controles.

Lo que sí se distribuye con buenos resultados: la aplicación de controles en cada sistema, la corrección de vulnerabilidades, el modelado de amenazas de cada producto, la primera revisión de cambios y la gestión de accesos del día a día. La regla práctica: se centraliza lo que define el criterio y se distribuye lo que lo aplica.

Security champions en los equipos de desarrollo

Un security champion es una persona de un equipo de desarrollo u operación que, sin dejar su rol, asume una responsabilidad adicional de seguridad: conoce las guías, detecta riesgos temprano, canaliza dudas al equipo central y difunde buenas prácticas. Es la pieza que hace viables los modelos federado y por producto sin multiplicar la plantilla de seguridad.

La OWASP Security Champions Guide reúne diez principios para estos programas. Entre ellos: partir de una visión clara del programa, asegurar el apoyo de la dirección, nombrar a una persona responsable de coordinarlo, construir una comunidad, reconocer la responsabilidad que asumen los champions, invertir en su formación y anticipar la rotación de personas. De nuestra parte, recomendamos además:

1. Asignar tiempo explícito. Un champion sin horas reservadas en la planificación del equipo es un voluntario que abandonará en el primer trimestre exigente. Por ejemplo, una fracción fija de su capacidad acordada con su líder.
2. Definir qué decide y qué escala. El champion puede aprobar cambios que cumplen la arquitectura de referencia; las excepciones van al centro.
3. Dar herramientas, no solo cursos. Plantillas de modelado de amenazas, listas de verificación por tipo de cambio y acceso a los hallazgos de su producto.
4. Medir el programa. Cuántos equipos tienen champion activo, tiempo de corrección de vulnerabilidades por equipo y consultas resueltas sin escalar.

Roles y responsabilidades con NIST CSF 2.0 y NICE

NIST CSF 2.0, publicado en febrero de 2024, incorporó la función Gobernar, y dentro de ella la categoría GV.RR (roles, responsabilidades y autoridades). Sus resultados esperados piden, en síntesis, que la alta dirección asuma la responsabilidad por el riesgo de ciberseguridad, que los roles y autoridades estén establecidos, comunicados, entendidos y aplicados, que los recursos sean adecuados a la estrategia y que la ciberseguridad forme parte de las prácticas de recursos humanos. Ampliamos la función completa en NIST CSF 2.0 y la función Gobernar.

GV.RR no dice qué modelo elegir. Pide que, cualquiera que sea, las responsabilidades estén escritas y se cumplan. Un formato útil es una matriz RACI por actividad (política, evaluación de riesgos, revisión de arquitectura, corrección de vulnerabilidades, respuesta a incidentes) con una columna por actor: CISO, equipo central, equipos de unidad o de producto, champions y dueños de negocio.

Para describir los puestos, el marco NICE (NIST SP 800-181 Rev. 1) ofrece un lenguaje común basado en declaraciones de tareas, conocimientos y habilidades, agrupadas en roles de trabajo. Usarlo evita que "analista de seguridad" signifique cosas distintas en cada unidad y facilita planificar la formación y la contratación.

Cómo elegir y cómo migrar

Recomendamos decidir con cuatro preguntas: cuántos equipos de entrega tienes y cómo trabajan, cuántas jurisdicciones regulatorias aplican, qué tan madura es tu plataforma interna y dónde están hoy las colas de seguridad. Con las respuestas, el modelo suele resultar evidente.

Cambiar de modelo no se hace de un día para otro. Un orden razonable: primero fijar las cuatro funciones centrales y la matriz de responsabilidades, después lanzar champions en los equipos de mayor riesgo y, solo cuando las guías y la plataforma funcionen, trasladar decisiones a los equipos. Antes de mover responsabilidades formales, conviene validar el diseño con Riesgo, Cumplimiento y Recursos Humanos, porque afecta líneas de reporte y obligaciones regulatorias.