10 preguntas que el consejo debe hacer sobre el SOC

Durante años, la supervisión del SOC era algo que los consejos delegaban en el CISO y revisaban después de un incidente. La regulación europea ha cerrado esa opción. NIS2 (Directiva (UE) 2022/2555), en su artículo 20, exige que el órgano de dirección apruebe las medidas de gestión de riesgos de ciberseguridad, supervise su implantación y reciba formación para entenderlas. Los miembros del órgano de dirección pueden ser considerados responsables por las infracciones. DORA (Reglamento (UE) 2022/2554) va más lejos para las entidades financieras: el órgano de dirección asume la responsabilidad final de la gestión del riesgo TIC, define la estrategia y aprueba la política sobre proveedores terceros de TIC.

No hay supervisión posible sin preguntas. Un consejero no puede aprobar medidas de riesgo que no sabe interrogar. Las 10 preguntas siguientes son deliberadamente no técnicas: no exigen entender una regla de SIEM ni una alerta de EDR. Exigen entender madurez, evidencia, dependencia, coste y rendición de cuentas. Ese es el lenguaje del consejo.

Lo que siempre contiene una buena respuesta. Tres elementos: un número o una fecha, la evidencia que lo respalda y el nombre de la persona responsable de moverlo. Cualquier respuesta a la que le falte uno de los tres es una opinión, no una respuesta.

1. ¿Cuál es la madurez de nuestro SOC en escala de 0 a 5, evaluada por un tercero independiente?

Por qué importa: es el único número que resume todo lo demás y ancla el deber de aprobación de NIS2. Por qué importa la independencia: los datos SOC-CMM 2026 muestran que las autoevaluaciones sobreestiman la madurez en unos 0,6 puntos, que es la distancia entre un SOC adecuado y uno expuesto. Una buena respuesta cita un SOC maturity assessment independiente contra el SOC-CMM, la puntuación por dominio, la fecha y la fecha de la próxima reevaluación.

2. ¿Cuáles son los tres riesgos más materiales que el SOC no cubre hoy?

Por qué importa: todo SOC tiene huecos; el peligro es un consejo que cree que no hay ninguno. Una buena respuesta nombra tres carencias concretas (por ejemplo, visibilidad limitada de redes OT, falta de cobertura fuera de horario laboral, una cobertura de detección en torno al 60% de las técnicas ATT&CK relevantes, que es la media intersectorial) y declara si cada una está aceptada, transferida o en el plan de mejora.

3. ¿Cuánto tardamos en detectar y contener un incidente real el último trimestre?

Por qué importa: la puntuación de madurez describe capacidad; esta pregunta comprueba si la capacidad se convierte en rendimiento. Una buena respuesta da las cifras reales del último incidente material o ejercicio, extraídas de los registros de tickets y no de la memoria, y las compara con los objetivos del propio SOC y con el reloj de notificación de NIS2: alerta temprana al CSIRT o autoridad en 24 horas, notificación del incidente en 72 horas.

4. Si nuestro MSSP fallara mañana, ¿cuánto tardaríamos en operar internamente?

Por qué importa: externalizar transfiere la operación, nunca la responsabilidad. DORA convierte el riesgo de terceros TIC en asunto de consejo, incluidas las estrategias de salida para proveedores críticos. Una buena respuesta declara la dependencia con honestidad, señala un plan de salida documentado y probado, y confirma que la organización, y no el proveedor, es dueña de los logs, los casos de uso y los runbooks.

5. ¿Qué evidencia tenemos de que los runbooks se siguen y se mantienen actualizados?

Por qué importa: un runbook que nadie sigue es papel mojado, y el proceso es donde los SOC son más débiles. En el conjunto de datos de 2026, el dominio Process promedia 2,3 sobre 5, por debajo de Technology con 2,7. Una buena respuesta señala fechas de revisión, muestras de tickets que demuestran que los pasos del runbook se ejecutaron y las conclusiones del último ejercicio de tabletop.

6. ¿Qué regulación nos obliga a reportar un incidente y en qué plazo?

Por qué importa: los plazos de notificación se miden en horas y el deber recae sobre la entidad, es decir, sobre su órgano de dirección. Una buena respuesta mapea las obligaciones reales de la entidad (plazos de NIS2, notificación de incidentes graves bajo DORA para entidades financieras, las 72 horas del RGPD para brechas de datos personales, más las normas sectoriales y nacionales) y demuestra que la lista de contactos y las plantillas existen antes de necesitarlas.

7. ¿Cuánto cuesta nuestro SOC al año y cómo se compara con el sector?

Por qué importa: un consejo que no ve el coste completo no puede juzgar si el SOC está infradotado o es ineficiente. Una buena respuesta presenta el coste total de propiedad: licencias, infraestructura, personas, el contrato del MSSP y la formación, con una comparación cualitativa frente a pares de tamaño y exposición regulatoria similares. La precisión importa menos que la completitud; el coste oculto es el modo de fallo.

8. ¿Qué tres KPIs definen el éxito del SOC y en qué tendencia van?

Por qué importa: diez cuadros de mando son ruido; tres indicadores con tendencia son gobernanza. Una buena respuesta elige tres medidas ligadas a resultados (por ejemplo, cobertura de detección, tiempo de contención y porcentaje de incidentes gestionados íntegramente según runbook), muestra al menos cuatro trimestres de tendencia y explica cualquier deterioro sin ponerse a la defensiva.

9. ¿Qué parte del SOC sería razonable externalizar, o internalizar, en los próximos 12 meses?

Por qué importa: el sourcing es una decisión estratégica que el consejo debe moldear, no descubrir. Una buena respuesta se apoya en la matriz de madurez: externalizar lo que está comoditizado y es 24/7, mantener interno lo que toca el contexto de negocio y las decisiones de crisis, y mostrar el análisis en lugar de una preferencia.

10. ¿Cuál es el plan de mejora aprobado y quién rinde cuentas de cada ítem?

Por qué importa: bajo NIS2 el órgano de dirección aprueba las medidas, así que un plan sin aprobar o sin dueños es una brecha de gobernanza directa. Una buena respuesta es una hoja de ruta priorizada derivada del último assessment independiente, con un responsable, una fecha y una partida presupuestaria por ítem, y una actualización de estado en cada revisión trimestral.

Cada pregunta admite una respuesta corta y una larga. La corta es el número. La larga es la evidencia. Esta tabla es la lista de verificación que un consejero, un auditor interno o un supervisor puede usar para distinguir una de otra.

El patrón es deliberado. Ocho de los diez elementos de evidencia ya existen en un SOC que ha pasado por un SOC maturity assessment independiente. Un consejo que institucionaliza estas preguntas no crea trabajo: consume evidencia que el assessment ya produjo.