SOC-CMM vs CMMI vs NIST CSF: qué framework elegir y cuándo

Los tres marcos nacieron para resolver problemas distintos, y ese origen explica casi todas sus diferencias prácticas. El SOC-CMM lo creó Rob van Os en 2016 como investigación de máster aplicada: un modelo de madurez y capacidad construido específicamente para centros de operaciones de seguridad, hoy en su versión 2.4 y citado por MITRE como referencia para evaluar SOCs. CMMI desciende del Capability Maturity Model del Software Engineering Institute de Carnegie Mellon, pensado en los años noventa para medir la madurez de procesos de desarrollo de software; hoy lo administra ISACA y se aplica a cualquier disciplina de procesos. NIST CSF apareció en 2014 como marco voluntario de ciberseguridad para infraestructuras críticas en Estados Unidos; su versión 2.0, publicada en febrero de 2024, amplió el alcance a cualquier organización y añadió la función Govern.

La consecuencia es directa: solo uno de los tres fue diseñado para responder la pregunta 'qué tan maduro es nuestro SOC'. Los otros dos pueden ayudar, pero responden preguntas adyacentes.

SOC-CMM mide dos cosas que conviene no confundir: madurez (qué tan bien definido, documentado y mejorado está cada aspecto) y capacidad (qué tan completa es la cobertura técnica y de servicios). Lo hace sobre 5 dominios, Business, People, Process, Technology y Services, desglosados en 27 aspectos. El informe SOC-CMM 2026 sitúa las medias globales por dominio en 2.5, 2.3, 2.3, 2.7 y 2.2 respectivamente: la tecnología suele ir por delante de las personas y los procesos.

NIST CSF no mide madurez. Mide cobertura de resultados de ciberseguridad organizados en seis funciones: Govern, Identify, Protect, Detect, Respond y Recover. Su salida natural es un perfil: el estado actual frente al estado objetivo. Sus tiers (1 a 4) describen el rigor de la gestión de riesgo, y el propio NIST advierte que no deben leerse como niveles de madurez.

CMMI mide madurez de procesos en abstracto: si un proceso está gestionado, definido, medido cuantitativamente y en mejora continua. Aplica igual a una fábrica de software que a un área de servicios. Existe contenido CMMI orientado a ciberseguridad, pero el modelo no sabe qué es un caso de uso de detección, una rotación de analistas de nivel 1 o una cobertura de MITRE ATT&CK.

El scoring es donde la elección se vuelve práctica. SOC-CMM puntúa cada aspecto en una escala continua de 0 a 5, lo que permite distinguir un 2.3 de un 2.7 y medir progreso real entre evaluaciones anuales. CMMI asigna niveles discretos del 1 al 5 a través de un appraisal formal, costoso y orientado a certificar la organización completa. NIST CSF no puntúa: contrasta perfiles, y cualquier escala numérica que vea sobre CSF es una capa que alguien añadió por encima del marco.

En evidencia, SOC-CMM trabaja por aspecto, con artefactos concretos: procedimientos de gestión de incidentes, matrices de casos de uso, planes de formación. Esto importa porque la distancia entre la percepción y la evidencia es real: el informe 2026 muestra que las autoevaluaciones sobreestiman la madurez en torno a 0.6 puntos frente a una evaluación independiente. Un marco con scoring continuo y evidencia por aspecto hace visible esa brecha; un nivel discreto o un perfil de cobertura la difumina.

Es habitual describir el SOC-CMM como 'el CMMI para SOCs'. La etiqueta es cómoda y técnicamente incorrecta. Comparten la idea genérica de madurez por niveles, pero difieren en lo esencial: el SOC-CMM no deriva de CMMI, no usa sus áreas de práctica, no requiere appraisal formal y puntúa en continuo, no en niveles discretos. Además incorpora la dimensión de capacidad, que CMMI no contempla: un SOC puede tener procesos maduros y aun así carecer de servicios completos de hunting o threat intelligence.

Cuidado con la etiqueta. Si un proveedor le presenta el SOC-CMM como 'CMMI para SOC', pida precisión. Son modelos distintos, con genealogía, scoring y evidencia distintos. La confusión suele anticipar una evaluación superficial.

Los dos marcos no compiten: se cruzan. Las funciones de CSF describen resultados que la organización entera debe lograr; los dominios SOC-CMM describen cómo el SOC los entrega. El mapeo no es uno a uno, pero hay correspondencias útiles para construir un cuadro coherente ante el consejo y el regulador.

La lectura inversa también ayuda: si su perfil CSF marca Detect como débil, la evaluación SOC-CMM le dice exactamente qué aspectos de Technology y Services explican esa debilidad, con un dato de contexto: la cobertura media de MITRE ATT&CK ronda el 60% según el informe 2026.

La decisión depende de la pregunta que tenga que responder. Si la pregunta del consejo es 'qué tan maduro es nuestro SOC y qué hacemos para mejorarlo', SOC-CMM es la respuesta directa: scoring continuo, evidencia por aspecto y roadmap priorizado. Si la pregunta es 'qué cobertura de controles tenemos como organización', NIST CSF da el lenguaje y el perfil. CMMI tiene sentido únicamente si la organización ya lo usa para otras disciplinas y quiere homogeneizar la gestión de procesos; en Europa y LATAM su adopción para SOCs es marginal.

• DORA (Reglamento (UE) 2022/2554) y NIS2 (Directiva (UE) 2022/2555) no exigen un marco concreto, pero piden demostrar capacidad y madurez de gestión de riesgos ICT con evidencia.
• El ENS aporta su propio esquema y acepta evidencia construida sobre NIST CSF o SOC-CMM como soporte.
• SBS 504-2021 (Perú) admite NIST CSF u otro marco internacional como referencia, lo que encaja con SOC-CMM como capa específica de SOC.
• Una evaluación independiente sobre SOC-CMM produce el artefacto que estos reguladores entienden: marco declarado, scoring documentado y plan de mejora con plazos.

La combinación sensata en entornos regulados: SOC-CMM para evaluar el SOC, NIST CSF como mapa de control transversal, y CMMI solo donde ya exista. Tres herramientas, tres preguntas, ninguna redundante si cada una se queda en su sitio.