Tiers y perfiles del NIST CSF 2.0: la forma sensata de medir madurez sin vender humo al consejo

Hay dos maneras de arruinar una conversación sobre madurez en ciberseguridad. La primera: convertirla en una discusión metafísica sobre si la organización es “nivel 3” o “nivel 4”. La segunda: llegar al consejo con un semáforo en PowerPoint, tres flechas ascendentes y cero contexto sobre qué riesgo baja realmente. El NIST CSF 2.0, actualizado este año como marco de referencia ya plenamente asentado en 2026, da herramientas para evitar ambas trampas. No hace magia, pero sí pone orden en una disciplina que demasiadas veces premia la estética del dashboard por encima de la utilidad.

La clave está en dos piezas que suelen citarse deprisa y usarse peor: los Tiers de implementación y los Profiles o perfiles actual y objetivo. Los primeros ayudan a describir cómo gestiona una organización el riesgo de ciberseguridad. Los segundos permiten comparar lo que hoy existe con lo que el negocio necesita de verdad. Juntos, bien trabajados, sirven para medir, priorizar y comunicar. Mal trabajados, generan exactamente lo contrario: una ilusión de precisión.

Para un CISO o un responsable de cumplimiento en Europa, el interés del CSF 2.0 no está en adoptar otro marco por puro coleccionismo normativo. Está en usar una gramática común que ayude a conectar controles, riesgo, exigencias regulatorias y decisiones ejecutivas. Si tienes que explicar al comité de auditoría por qué una dependencia crítica de terceros exige más presupuesto, o por qué un programa de gestión de vulnerabilidades no puede seguir evaluándose solo por número de parches aplicados, aquí tienes material serio. Y sí: también sirve para sobrevivir a la liturgia de DORA, NIS2, GDPR y auditorías internas sin inventarte una madurez de cartón piedra.

El CSF 2.0 mantiene las seis funciones del marco: Govern, Identify, Protect, Detect, Respond y Recover. El detalle importa porque la función Govern, incorporada de manera visible en la versión 2.0, resuelve un problema viejo: demasiadas organizaciones trataban la ciberseguridad como una colección de controles técnicos y no como un sistema de decisiones, responsabilidades, apetito de riesgo y supervisión. En 2026 eso ya no cuela. Ni ante el regulador ni ante el consejo.

Lo primero: los Tiers no miden “qué tan seguro” eres

Conviene empezar por la confusión más extendida. Los Implementation Tiers del NIST CSF 2.0 no son niveles de madurez lineales, no son una certificación, y no convierten a una empresa en “mejor” por el simple hecho de estar en un número más alto. NIST los describe como una forma de caracterizar la manera en que una organización gestiona el riesgo de ciberseguridad: si ese enfoque es ad hoc, repetible, integrado, basado en riesgo y conectado con objetivos de negocio.

Los cuatro Tiers siguen una lógica conocida:

• Tier 1 — Partial: las prácticas son reactivas y poco formalizadas; la gestión del riesgo no está integrada de forma consistente en la organización.
• Tier 2 — Risk Informed: existe conciencia del riesgo y ciertas prácticas aprobadas, pero la aplicación no es uniforme.
• Tier 3 — Repeatable: las políticas están aprobadas, se aplican de manera consistente y la gestión del riesgo forma parte de procesos recurrentes.
• Tier 4 — Adaptive: la organización ajusta sus prácticas a partir de lecciones aprendidas, inteligencia de amenazas y mejora continua.

El error habitual es usarlos como si fueran una escala escolar: uno es malo, cuatro es excelente. No funciona así. Un banco sistémico con operaciones transfronterizas, outsourcing crítico y exposición elevada a ataques de terceros no debería conformarse con prácticas parciales en dominios clave. Una pyme industrial con menor complejidad puede operar razonablemente con combinaciones menos ambiciosas en algunos ámbitos. El Tier adecuado depende del contexto de riesgo, de la criticidad del servicio, de la dependencia de terceros, de las obligaciones regulatorias y del coste de una interrupción.

Aquí está el quid: un Tier no resume “la madurez de ciberseguridad” de forma universal. Resume la sofisticación y consistencia del enfoque de gestión del riesgo. Eso cambia la conversación. Ya no preguntas “¿somos Tier 3?”. Preguntas “¿en qué capacidades y para qué procesos necesitamos operar al menos como Tier 3, y dónde sería racional quedarse en un enfoque menos maduro?”. Esa diferencia parece pequeña. No lo es. Ahí se decide si el marco sirve para gobernar o solo para decorar.

Además, el propio NIST evita presentar los Tiers como una trayectoria obligatoria de progreso. Esa prudencia regulatoria, rara vez tan explícita, merece ser tomada en serio. Si una entidad presume de “estar en Tier 4” de forma generalizada, probablemente está simplificando demasiado o maquillando. Casi ninguna organización grande y heterogénea mantiene el mismo nivel de sofisticación en gestión de activos, seguridad de terceros, desarrollo seguro, respuesta a incidentes, copias de seguridad, IAM y telemetría. La realidad es más fea y más útil: madurez desigual, dependencias cruzadas y decisiones de priorización incómodas.

Los perfiles son donde empieza el trabajo útil

Si los Tiers se llevan la fama, los Profiles hacen el trabajo serio. Un perfil actual describe el resultado de ciberseguridad que la organización está alcanzando hoy frente a las categorías y subcategorías del marco. Un perfil objetivo define el resultado que necesita alcanzar. La distancia entre ambos es el material de gestión: priorización, presupuesto, secuencia de ejecución, aceptación de riesgo y rendición de cuentas.

Eso suena elegante, pero la utilidad real aparece cuando se aterriza en categorías concretas del CSF 2.0. Por ejemplo, en la función Govern aparecen categorías como estrategia de gestión del riesgo de ciberseguridad, roles, políticas, supervisión de la cadena de suministro o comunicación. En Identify, la conversación va a activos, procesos críticos, riesgos, dependencias y entendimiento del entorno. En Protect, identidad, formación, gestión de datos, control de acceso y plataformas. En Detect, monitorización y análisis de anomalías. En Respond, análisis, contención, comunicación y mejora. En Recover, restauración y ajuste posterior.

Un perfil actual bien hecho no dice “tenemos EDR”, “hacemos pentests” o “hay política aprobada”. Describe hasta qué punto un resultado se logra de forma demostrable y consistente. Por ejemplo: “Los activos críticos que soportan servicios esenciales están inventariados y vinculados a un propietario de negocio, pero el inventario de dependencias SaaS no está completo y no existe trazabilidad sistemática con clasificación de datos”. Eso sí se puede discutir. Eso sí se puede auditar. Y eso sí se puede relacionar con impacto regulatorio.

El perfil objetivo, por su parte, no debería redactarse como un catálogo de deseos. Debe derivarse de necesidades de negocio, tolerancia al riesgo, obligaciones legales y dependencia operativa. Si tu entidad debe notificar incidentes significativos a la autoridad competente bajo DORA con plazos que pueden arrancar en una notificación inicial rápida y seguir con informes intermedios y finales según los RTS e ITS aplicables, o si está sujeta a NIS2 y a sus obligaciones de gestión de riesgos del artículo 21 y de notificación de incidentes del artículo 23, entonces el perfil objetivo no puede conformarse con capacidades improvisadas en monitorización, clasificación de incidentes, preservación de evidencias o coordinación con proveedores.

Traducido: el perfil objetivo no se fija mirando lo que hacen los vecinos ni lo que cabe en el presupuesto heredado. Se fija mirando qué tendrías que demostrar el día malo. El día del incidente. El día de la inspección. El día en que el consejo pregunta por qué una caída de un proveedor cloud ha dejado sin servicio un proceso crítico durante horas.

Qué añade de verdad el CSF 2.0 en 2026: gobernanza, cadena de suministro y lenguaje de negocio

La versión 2.0 del marco, publicada por NIST el 26 de febrero de 2024, hizo algo más relevante que un simple reordenamiento cosmético: dio peso estructural a la gobernanza. Eso importa mucho en 2026 porque buena parte del endurecimiento regulatorio europeo se está moviendo justo ahí. DORA obliga a que el órgano de dirección defina, apruebe, supervise y sea responsable del marco de gestión del riesgo de las TIC; eso está en el artículo 5. NIS2 refuerza la responsabilidad de la dirección en su artículo 20 y obliga a medidas de gestión de riesgos en su artículo 21. El GDPR, por su lado, no habla el lenguaje del CSF, pero sí exige seguridad apropiada al riesgo en el artículo 32 y notificación de brechas a la autoridad de control en 72 horas en el artículo 33.

Lo interesante no es que estos textos digan exactamente lo mismo; no lo hacen. Lo interesante es que todos empujan en la misma dirección: dejar de tratar la ciberseguridad como un asunto exclusivamente técnico. El CSF 2.0 resulta útil porque ofrece un marco neutral para conectar esa exigencia con prácticas reales. La función Govern permite construir un relato que el consejo entiende: quién decide, con qué criterios, qué se acepta, qué se transfiere, qué se corrige primero y cómo se mide si el programa reduce riesgo operativo.

La segunda mejora práctica es la atención a la cadena de suministro. La obsesión regulatoria no es caprichosa. Los últimos años han dejado bastante evidencia de que una organización puede hacer bien muchas cosas y aun así caer por la pieza ajena más débil: proveedor SaaS, MSP, librería de software, servicio de autenticación o integrador con acceso privilegiado. DORA dedica su Capítulo V a la gestión del riesgo asociado a terceros prestadores de servicios de TIC, y su artículo 28 fija los principios generales de gestión de ese riesgo. NIS2, en el artículo 21.2.d, incluye expresamente la seguridad de la cadena de suministro. El CSF 2.0 encaja aquí porque permite mapear esas obligaciones en resultados concretos: inventario de proveedores críticos, cláusulas contractuales, monitorización continua, planes de salida, dependencias técnicas reales y pruebas de contingencia.

La tercera mejora es menos vistosa y más importante: el marco sirve para hablar con finanzas, auditoría, legal, operaciones y negocio sin obligarles a interpretar jerga defensiva. Un perfil actual/objetivo bien diseñado convierte discusiones técnicas dispersas en decisiones comprensibles. No se trata de “subir la madurez de SIEM a Tier 4”; se trata de demostrar que, para servicios críticos, la organización puede detectar actividad anómala, clasificarla con criterios uniformes, escalarla según severidad, activar playbooks y conservar evidencias para requisitos regulatorios y forenses. El consejo no necesita saber configurar una regla Sigma. Necesita saber si la entidad aguanta un incidente serio sin improvisar.

Por qué casi todas las autoevaluaciones de madurez fallan

Hay una razón bastante simple: intentan producir una nota única. El problema es metodológico. Una única puntuación general aplasta diferencias esenciales entre dominios, ignora dependencias, esconde excepciones y da a la dirección una falsa sensación de comparabilidad. Cuando una organización dice que su madurez es “3,2 sobre 5”, nadie sabe qué significa para continuidad, para gestión de identidades, para seguridad del desarrollo o para terceros críticos. Pero queda bonito en comité. Y a veces eso parece suficiente hasta que deja de serlo.

El CSF 2.0 funciona mejor si se usa como estructura de conversación y priorización, no como generador de un número elegante. Lo sensato es evaluar resultados por categoría y, cuando haga falta, por subcategoría. Después se añaden dos capas: evidencia y criticidad. Evidencia significa que cada valoración tiene soporte objetivo. Criticidad significa que no todos los huecos pesan igual.

Un ejemplo operativo. Dos carencias posibles:

• No existe una taxonomía uniforme para clasificar activos según criticidad y sensibilidad de datos.
• El programa de phishing simulado lleva nueve meses sin ejecutarse.

Ambas son deficiencias. No tienen el mismo peso. La primera compromete inventario, priorización de controles, respuesta a incidentes, continuidad, gestión de terceros y cumplimiento de múltiples marcos. La segunda afecta a concienciación, pero probablemente no justifica la misma urgencia si ya existen otras medidas compensatorias. Si tu modelo de madurez produce la misma severidad para ambos problemas, el modelo necesita terapia.

Otro fallo clásico: confundir existencia documental con capacidad operativa. Política aprobada no equivale a proceso implantado. Proceso implantado no equivale a resultado medible. Resultado medible en un área piloto no equivale a cobertura empresarial. La diferencia es decisiva en una auditoría seria. También en una crisis real. Si declaras que tienes respuesta a incidentes madura, pero no puedes demostrar tiempos de detección, tiempos de escalado, calidad de los runbooks, cobertura de logs, dependencia de terceros o capacidad de comunicación regulatoria, no tienes una capacidad madura. Tienes un documento y cierta esperanza.

Un tercer fallo, más sutil, aparece cuando los equipos califican madurez técnica sin incorporar gobernanza ni negocio. Ahí el CSF 2.0 vuelve a poner orden. Una organización no es más madura por tener muchas herramientas; lo es cuando esas herramientas están conectadas con decisiones de riesgo, responsabilidades claras, métricas útiles y mejora sostenida. Si no, lo que tienes es un armario caro.

Cómo usar Tiers y perfiles sin convertirlos en teatro corporativo

El enfoque correcto no empieza por poner notas. Empieza por delimitar el objeto de evaluación. ¿Qué quieres medir exactamente? ¿La empresa entera? ¿Una unidad de negocio? ¿Los servicios críticos? ¿El entorno cloud? ¿Las capacidades que sostienen cumplimiento con DORA y NIS2? Si intentas abarcar todo de golpe, obtendrás una foto borrosa.

Para organizaciones europeas con obligaciones regulatorias intensas, la unidad más útil suele ser el servicio o proceso crítico, no el departamento técnico. Tiene lógica. DORA gira alrededor de funciones críticas o importantes y del riesgo ICT asociado. NIS2 está orientada a entidades esenciales e importantes y a la continuidad del servicio. El GDPR fuerza a pensar en tratamientos, datos y riesgo para derechos y libertades. Si evalúas madurez alrededor de un servicio crítico —por ejemplo, pagos, onboarding digital, gestión de pólizas, autenticación de clientes, trading, atención clínica o cadena logística—, la conversación se vuelve mucho más concreta.

Después hay que construir el perfil actual con evidencia mínima viable. No hace falta crear una burocracia paralela, pero sí evitar la autoindulgencia. La evidencia típica incluye políticas vigentes, asignación formal de roles, inventario de activos y dependencias, contratos con terceros, resultados de pruebas, cobertura de monitorización, métricas de parcheo basadas en criticidad, registros de formación, actas de comités, ejercicios de respuesta a incidentes, evidencias de restauración y análisis post-incidente. Si una valoración no puede vincularse a una de esas fuentes, probablemente es opinión. Y la opinión, en gestión de riesgo, cotiza peor de lo que algunos creen.

El perfil objetivo exige otro ejercicio: definir resultados necesarios y no aspiracionales. Hay que preguntarse qué exige el negocio para tolerar una interrupción, qué tiempos de recuperación son aceptables, qué dependencias no tienen sustituto, qué compromisos contractuales existen, qué exige la supervisión y qué escenarios de amenaza son plausibles. Un proveedor de servicios financieros con fuerte externalización cloud no necesita el mismo perfil objetivo que una manufacturera mediana con baja exposición regulatoria. Esto parece obvio, pero la industria aún pierde demasiadas horas copiando benchmarks ajenos.

Una vez comparas perfil actual y perfil objetivo, ya puedes decidir dónde aplicar el lenguaje de Tiers. El Tier no debería ser el punto de partida, sino una forma de describir el grado de institucionalización del enfoque en aquellas áreas críticas. Eso ayuda mucho frente al consejo. Decir “nuestra gestión de terceros críticos opera hoy con rasgos de Tier 2: hay criterios y revisiones, pero no una aplicación consistente, monitorización continua suficiente ni pruebas regulares de salida” es bastante más honesto y útil que una nota global de 68%.

La pieza que el consejo sí entiende: riesgo, dependencia y decisión

Los consejos de administración no necesitan una clase sobre taxonomías de controles. Necesitan entender tres cosas: qué riesgo importa, qué decisión se les pide y qué pasa si no la toman. El CSF 2.0 ayuda a estructurarlo porque los perfiles pueden presentarse como brechas entre resultados actuales y necesarios, y los Tiers como grado de fiabilidad del enfoque de gestión.

La mejor comunicación al consejo suele tener esta forma narrativa:

1. Se identifica un servicio crítico y el impacto de su interrupción en ingresos, cumplimiento, cliente o continuidad.
2. Se describen las dependencias principales: activos, datos, terceros, personal clave, procesos manuales y puntos únicos de fallo.
3. Se mapea el perfil actual contra categorías relevantes del CSF 2.0.
4. Se define el perfil objetivo con base en riesgo y obligaciones concretas.
5. Se explican las brechas con una traducción a exposición operativa y regulatoria.
6. Se pide una decisión: invertir, aceptar riesgo, cambiar arquitectura, renegociar contratos o reducir dependencia.

Eso ya es gobierno corporativo. El resto son adornos. Bastante caros, a veces.

Un ejemplo que funciona. Servicio crítico: autenticación de clientes en banca digital. Perfil actual: cobertura fuerte de MFA para empleados, pero inconsistencias en autenticación reforzada de clientes, dependencia concentrada de un proveedor externo de mensajería y escasa capacidad de failover probada. Perfil objetivo: resiliencia suficiente para soportar caída del proveedor principal sin degradar autenticación más allá del umbral aceptado por el negocio y manteniendo trazabilidad de eventos. Brecha: alta dependencia de tercero, pruebas de continuidad insuficientes, telemetría dispersa. Decisión de consejo: financiar redundancia, revisar contrato, exigir pruebas de conmutación y aceptar el coste operativo. Ese es el tipo de conversación que cambia exposición real.

Conectar NIST CSF 2.0 con DORA, NIS2 y GDPR sin hacer un Frankenstein

El riesgo de cualquier organización regulada es acabar con tres mapas distintos para la misma realidad: uno para ciberseguridad, otro para continuidad, otro para cumplimiento. Resultado: fatiga, duplicidades y discusiones absurdas sobre etiquetas en lugar de problemas. El CSF 2.0 puede funcionar como capa de organización, pero solo si se usa con disciplina.

Tomemos algunos puntos concretos. DORA exige un marco interno sólido para gestionar riesgo ICT, con gobernanza del órgano de dirección en el artículo 5, un marco de gestión del riesgo ICT en el artículo 6, gestión de incidentes en el artículo 17 y gestión del riesgo de terceros TIC en el artículo 28. NIS2, en su artículo 21, obliga a medidas técnicas, operativas y organizativas adecuadas y proporcionales, incluyendo gestión de incidentes, continuidad, seguridad de la cadena de suministro, seguridad en adquisición, desarrollo y mantenimiento, evaluación de eficacia y formación. El GDPR exige medidas apropiadas en el artículo 32 y notificación a la autoridad en el artículo 33 cuando haya violación de seguridad de los datos personales.

Si montas un perfil del CSF 2.0 por servicio crítico, puedes enlazar categorías y resultados a estas obligaciones sin necesidad de crear un lenguaje distinto para cada una. La función Govern conversa bien con responsabilidad de dirección, políticas, apetito de riesgo y reporting. Identify ayuda a ordenar activos, tratamientos, dependencias y criticidad. Protect agrupa controles preventivos que son comunes a casi todos los marcos. Detect y Respond son el puente natural hacia notificación de incidentes, coordinación interna, cadena de custodia y escalado. Recover aterriza continuidad y restauración.

Pero hay una advertencia: mapear no equivale a cumplir. Que una subcategoría del CSF “cubra” conceptualmente un requisito no significa que hayas satisfecho la evidencia regulatoria ni el nivel de detalle exigido. DORA, por ejemplo, tiene expectativas específicas sobre testing, gestión de terceros y gobernanza. NIS2 dependerá también de la transposición nacional y de la práctica supervisora. El GDPR sigue teniendo su propia lógica de riesgo para derechos y libertades, base jurídica, minimización y accountability. El CSF 2.0 es un idioma común, no un pase VIP.

Lo útil para compliance es que evita diseñar programas separados. Lo útil para el CISO es que permite explicar al área legal y al consejo que varias exigencias aparentemente distintas descansan en las mismas capacidades operativas. Si tu capacidad de clasificación de activos, dependencia de terceros y monitorización de incidentes es débil, no fallas en un único marco. Fallas en varios a la vez. Y el presupuesto, por una vez, puede defenderse con una lógica menos tribal.

No todas las categorías valen lo mismo: priorizar por servicio crítico, no por moda

Uno de los vicios más caros del mercado es invertir donde la tecnología luce mejor y no donde la dependencia es mayor. El CSF 2.0 permite evitar esa dispersión si se acepta una idea incómoda: la prioridad no la marca la herramienta, la marca el servicio crítico y su riesgo asociado.

Para un entorno de servicios financieros, por ejemplo, hay categorías que casi siempre merecen una atención más alta: inventario fiable de activos y dependencias, clasificación de criticidad, IAM con control de privilegios, seguridad de terceros, registro y monitorización, respuesta a incidentes, recuperación probada y gobierno con reporting útil. Si eso está flojo, la conversación sobre comprar otra capa de analítica avanzada puede esperar.

En sectores con cadena de suministro industrial o sanitaria, la prioridad puede desplazarse a segmentación, visibilidad sobre activos OT/IoT, continuidad de procesos clínicos o de planta, gestión de accesos de terceros y restauración segura. El punto no es que unas categorías sean siempre más importantes que otras. El punto es que el perfil objetivo debe derivarse de lo que no puedes permitirte perder.

Una práctica recomendable es asignar a cada brecha tres atributos: criticidad del servicio afectado, severidad de la brecha y dependencia externa. Cuando coinciden alta criticidad, alta severidad y fuerte dependencia de terceros, la urgencia sube de verdad. Eso además encaja con la sensibilidad regulatoria actual. Los supervisores europeos llevan tiempo mirando no solo si tienes controles, sino si entiendes tus concentraciones de riesgo y tus puntos de fallo compartidos.

Cómo evitar la inflación de Tier 4

Hay algo casi cómico en muchas autoevaluaciones: cuanto más arriba presenta una organización su “madurez”, menos evidencia concreta suele enseñar. Es la inflación reputacional de la ciberseguridad. Todos quieren estar en la zona noble del gráfico. Pocos quieren discutir si realmente aprenden de incidentes, adaptan controles con rapidez, integran inteligencia de amenazas en decisiones operativas y ajustan su estrategia con métricas fiables. Eso es lo que implicaría, en esencia, un enfoque cercano a Tier 4 — Adaptive.

La pregunta útil no es si tu empresa quiere ser Tier 4. Claro que quiere. También querría volar, pagar menos licencias y que los proveedores respondan al cuestionario de due diligence en una tarde. La pregunta útil es dónde merece la pena aspirar a un enfoque adaptativo y dónde el retorno no compensa. Para algunos procesos y servicios críticos, la adaptación continua basada en señales y lecciones aprendidas puede ser razonable. Para otros, bastará con prácticas repetibles y bien gobernadas.

Un criterio pragmático: reserva las aspiraciones de mayor sofisticación para capacidades donde convergen cuatro factores: alto impacto de negocio, dependencia tecnológica compleja, obligación regulatoria intensa y rapidez en el cambio de amenaza. Terceros críticos, detección y respuesta, IAM privilegiado, seguridad de entornos cloud y restauración de servicios esenciales encajan a menudo en esa lista. Otras áreas pueden operar correctamente con menos sofisticación si el riesgo lo permite.

Esta distinción ayuda también a no castigar injustamente a equipos que hacen bien lo importante. Una organización no fracasa por no tener la perfección adaptativa en todo. Fracasa por no saber dónde necesita fiabilidad alta y seguir tratando esas brechas como deuda técnica ornamental.

Métricas que no insulten la inteligencia del consejo

Si vas a usar perfiles y Tiers para reportar a la dirección, las métricas importan más que el diseño del dashboard. Aquí la tentación habitual es medir actividad y llamarla resultado. Número de parches, número de alertas, número de formaciones, número de políticas revisadas. Todo eso puede ser útil internamente. Ninguna de esas métricas, por sí sola, responde a la pregunta que el consejo hace de verdad: “¿Estamos reduciendo exposición en lo que puede interrumpir el negocio o generar un problema regulatorio serio?”.

Las métricas más útiles al nivel ejecutivo suelen combinar cobertura, tiempo, criticidad y tendencia. Por ejemplo:

• Porcentaje de servicios críticos con inventario completo de dependencias técnicas y de terceros validado en los últimos 12 meses.
• Porcentaje de activos críticos con registros centralizados suficientes para investigación y retención alineada con requisitos internos y regulatorios.
• Tiempo mediano desde detección a clasificación de incidentes de severidad alta.
• Porcentaje de proveedores TIC críticos con evaluación reforzada, cláusulas de incidente y pruebas de contingencia revisadas.
• Porcentaje de restauraciones de servicios críticos probadas con éxito frente a RTO y RPO definidos por negocio.

Esas métricas ya se pueden conectar con perfiles actuales y objetivos. Si el objetivo es que el 95% de los servicios críticos tenga dependencias validadas y hoy estás en el 61%, la brecha es visible. Si además explicas que esos servicios soportan pagos, onboarding o atención clínica, el consejo entiende por qué importa. No hace falta disfrazarlo con un índice compuesto de “resiliencia digital” de 7,4 sobre 10. Gracias, pero no.

Una tabla útil: cómo llevar Tiers y perfiles a decisiones concretas

La tabla no pretende crear otro formulario. Pretende mostrar la diferencia entre actividad declarativa y capacidad demostrable. Esa diferencia, en auditoría o en crisis, se vuelve dolorosamente real.

Implicaciones para entidades financieras europeas

Para banca, seguros, pagos, gestión de activos y fintech regulada en Europa, usar el CSF 2.0 como lenguaje de madurez tiene una ventaja inmediata: permite ordenar el programa de resiliencia sin duplicar taxonomías. DORA ya está plenamente en el centro de las prioridades operativas este año, y su lógica es inequívoca: gobierno del riesgo ICT, clasificación y gestión de incidentes, pruebas de resiliencia, terceros críticos y supervisión del órgano de dirección.

Eso hace que el perfil objetivo de una entidad financiera no pueda construirse en abstracto. Debe reflejar, como mínimo, capacidades defendibles en cinco frentes:

• Gobierno y reporting: la dirección debe recibir información accionable, no métricas ornamentales. DORA art. 5 no invita; exige responsabilidad del órgano de dirección.
• Inventario y criticidad: sin trazabilidad clara entre activos, servicios, procesos y terceros, el marco de gestión del riesgo ICT del art. 6 pierde sustancia.
• Incidentes: la capacidad de detectar, clasificar, escalar y notificar no puede depender de heroicidades manuales. DORA art. 17 y el régimen de reporte posterior no perdonan improvisaciones.
• Terceros TIC: la dependencia operativa de cloud, SaaS, MSP e integradores exige una madurez visible y demostrable. DORA art. 28 lo deja bastante claro.
• Pruebas y recuperación: si la recuperación no se prueba sobre servicios críticos con escenarios plausibles, no hay resiliencia; hay fe.

Para estas entidades, el uso inteligente de Tiers consiste en mostrar al consejo dónde el enfoque actual sigue siendo “risk informed” cuando ya debería ser “repeatable” o “adaptive” por criticidad y dependencia. Ese salto no es terminología: justifica inversión, priorización contractual y decisiones de arquitectura. También ayuda a alinear ciberseguridad con continuidad, outsourcing, riesgo operacional y compliance. Algo casi revolucionario, dado lo poco que suelen hablarse entre sí esos mundos salvo cuando ocurre un incidente.

Qué debería hacer un CISO mañana mismo con este marco

No hace falta relanzar todo el programa de seguridad ni contratar otra evaluación mastodóntica. Hace falta escoger bien el punto de entrada. La mejor secuencia suele ser bastante sobria.

Empieza por un servicio crítico de verdad, no por un área cómoda. Identifica su cadena de dependencias: aplicaciones, datos, terceros, identidades privilegiadas, procesos manuales, integraciones y requisitos regulatorios. Construye un perfil actual del CSF 2.0 con evidencia concreta y sin piedad por la documentación decorativa. Define luego un perfil objetivo limitado a lo que el negocio necesita para operar dentro de su tolerancia al riesgo y para soportar escrutinio regulatorio. Solo después usa los Tiers para describir el grado de institucionalización de las capacidades críticas. No al revés.

El siguiente paso es preparar un informe ejecutivo que responda a tres preguntas. Primero: qué brechas afectan al servicio crítico y por qué. Segundo: qué decisión exige cada brecha —presupuesto, cambio de proveedor, refuerzo de controles, revisión contractual, simplificación arquitectónica o aceptación formal del riesgo—. Tercero: qué evidencia demostrará mejora en un plazo razonable. Si no puedes responder a esas tres preguntas, todavía no estás usando el marco; estás clasificando conceptos.

Una recomendación adicional para responsables de cumplimiento: integra desde el inicio el mapa entre categorías del CSF 2.0 y obligaciones concretas de DORA, NIS2 y GDPR que sí apliquen a tu entidad. No para presumir de cobertura, sino para evitar dobles demandas de evidencia. Cuando auditoría interna, ciberseguridad y compliance piden pruebas distintas de la misma capacidad, la organización paga tres veces por la misma conversación y aprende la mitad.

La conclusión incómoda: la madurez útil no cabe en una sola cifra

Los Tiers del NIST CSF 2.0 son valiosos precisamente porque no prometen una respuesta simple. Los perfiles son potentes precisamente porque obligan a comparar capacidades actuales con resultados necesarios. Ese diseño incomoda a quien quiere una nota única, un benchmark vistoso o una etiqueta que suene bien ante el consejo. Mala suerte. La gestión seria del riesgo no suele venir en formato eslogan.

Si tu organización usa los Tiers como medalla y los perfiles como checklist burocrática, perderá tiempo. Si los usa para describir con honestidad cómo gestiona el riesgo, qué resultados necesita por servicio crítico y qué decisiones ejecutivas faltan, ganará algo mucho más raro: claridad. Y en ciberseguridad, la claridad ya es media defensa.

La ironía final es esta: el marco que mejor ayuda a comunicar madurez al consejo es el que menos se presta a vender una fantasía de control total. Justo por eso merece la pena. Porque en 2026 lo que diferencia a un programa serio no es cuántos gráficos muestra, sino cuánto riesgo real sabe explicar, priorizar y reducir.