Errores comunes en assessments SOC-CMM y cómo evitarlos

La mayoría de los assessments SOC-CMM defectuosos fallan de las mismas pocas maneras. El hallazgo es consistente en las evaluaciones que revisamos: el problema rara vez es el modelo. El SOC-CMM, creado por Rob van Os en 2016 y hoy en la versión 2.4, le da cinco dominios, 27 aspectos y una escala continua de puntuación de 0 a 5. Esa estructura basta para producir un resultado defendible. Lo que rompe el resultado es cómo se ejecuta el scoring, quién lo reta y qué ocurre después de entregar el informe.

El coste de estos errores es concreto. Un consejo aprueba un presupuesto de mejora contra un número de madurez. Un regulador bajo NIS2 (Directiva (UE) 2022/2555) o DORA (Reglamento (UE) 2022/2554) lee el assessment como evidencia de supervisión. Si el número está inflado o falta la evidencia, ambas decisiones se apoyan en arena. A continuación, los errores que más vemos, agrupados según dónde entran en el proceso.

El patrón más dañino es aceptar una autoevaluación como línea base sin reto externo. El dato es inequívoco: cuando un assessor independiente valida resultados autoevaluados, las autoevaluaciones sobreestiman la madurez en torno a 0,6 puntos sobre la escala 0-5. No es un error de redondeo. Es la diferencia entre reportar un SOC en 3,0 y descubrir que opera en 2,4.

El sesgo es estructural, no deshonesto. Las personas que puntúan el SOC son las que lo construyeron. Puntúan el diseño que pretendían, rellenan huecos de memoria y leen con generosidad las preguntas ambiguas. Nada de esto exige mala fe; solo exige la ausencia de alguien cuyo trabajo sea pedir la evidencia detrás de cada respuesta. La autoevaluación sigue siendo útil como preparación. Deja de serlo en el momento en que se presenta a un consejo o a un regulador como hallazgo independiente.

La brecha de 0,6 puntos. Un 3,0 autoevaluado que en realidad es un 2,4 no solo desinforma al consejo. Desprioriza exactamente el trabajo de mejora que el SOC necesita, porque la puntuación inflada sugiere que ese trabajo ya está hecho. La corrección siempre cuesta más de lo que habría costado el reto.

Muy relacionado, y presente incluso en assessments con ejecución externa: puntuar lo que el SOC pretende hacer en lugar de lo que demuestra hacer. Un catálogo de casos de uso que existe como elemento del roadmap se puntúa como desplegado. Un runbook redactado el mes pasado se puntúa como ejercitado. Una guardia acordada de palabra se puntúa como documentada y probada.

La disciplina que lo evita es simple de enunciar: cada puntuación necesita un artefacto detrás. Un documento, una entrevista que lo corrobore y una muestra (un ticket, un dashboard, una ejecución de runbook) que demuestre que la práctica es real. Cuando los tres alinean, la puntuación es defendible ante cualquier audiencia. Cuando el assessor no puede producirlos, la puntuación honesta es la más baja. La escala continua del SOC-CMM existe precisamente para que las prácticas parciales o en curso puntúen como parciales, no como completas.

El SOC-CMM mide dos cosas distintas y los equipos las mezclan de forma rutinaria. La madurez pregunta cómo de bien gestionada está una práctica: documentada, medida, revisada, mejorada. La capacidad pregunta cómo de completa es la función: si el SOC tiene de verdad las personas, los procesos y la tecnología para ejecutarla. Un SOC puede operar un conjunto pequeño de detecciones con alta madurez. También puede poseer un stack tecnológico caro con muy baja madurez en cómo se opera.

Cuando ambas se promedian en un único número indiferenciado, el informe no responde a ninguna de las dos preguntas. El consejo no puede saber si la brecha es capacidad ausente (una decisión de inversión) o capacidad sin gestionar (una decisión de gobierno). Mantenga las dos lecturas separadas en el scoring y separadas en el informe. Los caminos de remediación son distintos, y también lo son las conversaciones de presupuesto.

El SOC-CMM tiene cinco dominios: Business, People, Process, Technology y Services. Los assessments liderados por perfiles de ingeniería gravitan hacia Tecnología y Proceso y tratan Business y People como blandos, opcionales o N/A. Los datos sectoriales de 2026 muestran por qué eso es exactamente al revés: la madurez media es 2,7 en Tecnología pero 2,5 en Business, 2,3 en People, 2,3 en Process y 2,2 en Services. Los dominios más débiles son los que más se omiten. Gobierno, mandato, alineamiento presupuestario, dotación, formación y retención son donde los SOC son menos maduros, y un assessment que los omite certifica la mitad fuerte del SOC mientras ignora la mitad que falla primero bajo presión.

El error relacionado es tratar esos promedios sectoriales como objetivos. Un promedio es una descripción del sector, no una meta. Un SOC de telecomunicaciones que defiende infraestructura crítica bajo NIS2 puede necesitar 3,5 en gestión de incidentes mientras 2,5 es aceptable en otro entorno. El objetivo de madurez debe derivarse de su perfil de riesgo, su exposición regulatoria y sus compromisos de servicio, dominio a dominio. 'Estamos por encima de la media' no es una posición defendible ante un supervisor; 'cumplimos el objetivo que justificamos para cada dominio' sí lo es.

Dos errores de proceso determinan si el assessment sobrevive al escrutinio. El primero es no construir un dossier de evidencia: una colección versionada que enlaza cada puntuación con los documentos, notas de entrevista y muestras que la justifican. Sin él, el assessment no puede defenderse seis meses después, cuando auditoría interna, un supervisor o un nuevo CISO pregunte cómo se llegó a un número. Con él, esas mismas preguntas se responden en minutos.

El segundo es tratar el assessment como un evento único. Una sola medición no demuestra nada sobre la dirección. El valor de una evaluación de madurez se compone en la segunda y tercera iteración, cuando el consejo ve una línea de tendencia: qué dominios se movieron, si el roadmap entregó, dónde la inversión se tradujo en mejora medida. Cierre cada assessment con el siguiente ya en el calendario, típicamente a doce meses, y con cada elemento del roadmap con responsable y fecha. Un assessment sin ciclo de re-evaluación es una foto; los reguladores y los consejos están pidiendo una película.

• Fije el alcance por escrito antes de empezar el scoring: entidades, geografías, horarios de cobertura y qué opera el MSSP frente a qué opera usted.
• Exija la prueba de evidencia en tres partes (documento, entrevista, muestra) para cada puntuación por encima de 2.
• Reporte madurez y capacidad como lecturas separadas por dominio.
• Defina objetivos derivados del riesgo por dominio; use los promedios sectoriales solo como contexto.
• Programe el re-baseline antes de que termine la reunión de cierre.