NIST CSF 2.0 e ISO 27001: cómo usar ambos sin duplicar trabajo

La discusión sobre si conviene trabajar con NIST CSF 2.0 o con ISO/IEC 27001 suele empezar mal: como si hubiera que casarse con uno y renunciar al otro. Para un CISO europeo, ese planteamiento ya llega viejo. La pregunta útil no es cuál gana, sino cómo usar ambos sin construir dos programas paralelos, dos catálogos de control y, peor aún, dos fábricas de evidencias que nadie mantiene con gusto.

La respuesta corta: NIST CSF 2.0 sirve muy bien para ordenar conversaciones de riesgo, prioridades y resultados; ISO/IEC 27001:2022 sirve mejor para estructurar un sistema de gestión auditable, con responsabilidades, documentación y mejora continua. Uno habla el idioma del outcome. El otro, el de la certificación y la disciplina organizativa. Si los tratas como universos distintos, duplicas trabajo. Si los conectas bien, el CSF se convierte en la vista operativa de tu ISMS y el Anexo A de ISO en la capa de control y evidencia que evita que todo quede en PowerPoint.

Desde febrero de 2024, cuando NIST publicó la versión 2.0 del Cybersecurity Framework, esta complementariedad es todavía más clara. La gran novedad no fue un giro dramático en controles técnicos; fue la incorporación explícita de la función Govern. NIST, en otras palabras, admitió algo que los auditores de ISO llevan años repitiendo con una paciencia casi monástica: sin gobierno, roles, apetito de riesgo, políticas y supervisión, la ciberseguridad es una colección de herramientas caras.

Para empresas europeas, además, el debate ya no es académico. Si tu organización toca datos personales, ahí está el RGPD con el artículo 32 sobre seguridad del tratamiento, el artículo 33 sobre notificación de brechas en 72 horas y el artículo 35 sobre evaluaciones de impacto. Si estás bajo NIS2, el artículo 21 exige medidas de gestión de riesgos de ciberseguridad y el artículo 23 impone obligaciones de notificación con plazos concretos. Si eres entidad financiera o proveedor TIC crítico del sector, DORA aprieta por varios frentes: gestión del riesgo TIC en los artículos 5 a 16, notificación de incidentes en los artículos 17 a 23, pruebas de resiliencia en los artículos 24 a 27 y terceros TIC en los artículos 28 a 30. Ninguno de esos marcos te pregunta si prefieres NIST o ISO. Te preguntan si puedes demostrar control, gobierno, respuesta y mejora.

Aquí está el quid: NIST CSF 2.0 e ISO 27001 no deben implantarse como dos marcos, sino como dos vistas sobre el mismo sistema.

Lo que realmente aporta NIST CSF 2.0 y por qué no sustituye a ISO 27001

NIST CSF 2.0 mantiene la estructura de funciones que ya conocen casi todos los equipos de seguridad: Identify, Protect, Detect, Respond y Recover. La novedad es Govern, situada deliberadamente al principio. No es cosmética. Cambia la manera de mapear responsabilidades y de explicar al comité de dirección por qué ciertos controles no son “proyectos de TI”, sino exigencias de gestión del riesgo empresarial.

La función Govern agrupa categorías relacionadas con estrategia, política, roles, supervisión, cadena de suministro, apetito de riesgo y vigilancia de obligaciones legales y regulatorias. Esto se parece bastante al corazón de ISO/IEC 27001:2022: contexto de la organización, liderazgo, planificación, soporte, operación, evaluación del desempeño y mejora. Es decir, las cláusulas 4 a 10 del estándar, no solo el Anexo A. Y aquí suele cometerse el primer error práctico: comparar NIST CSF solo con el Anexo A de ISO 27001. Eso produce un mapa incompleto, porque Anexo A contiene controles, pero ISO 27001 no se reduce a controles. También exige un sistema de gestión.

Si te limitas a decir que una categoría de NIST “equivale” a un control de Anexo A, te dejas fuera las piezas que hacen que ese control funcione en auditoría: propietario, criterio de aceptación, método de revisión, evidencias, desviaciones y acciones correctivas. El resultado es muy común: una organización puede afirmar con honestidad que tiene capacidades alineadas con NIST, pero suspender una auditoría ISO porque no demuestra consistencia, revisión periódica o trazabilidad de decisiones.

ISO/IEC 27001:2022, por su parte, sigue siendo el marco más cómodo cuando el objetivo es construir una arquitectura auditable. El Anexo A de la versión 2022 redujo y reorganizó los controles a 93, agrupados en cuatro temas: organizativos, de personas, físicos y tecnológicos. Esa simplificación no significa menos trabajo; significa que el estándar dejó de premiar el check-box de catálogo y empujó a organizaciones y auditores hacia una lectura más integrada. La Declaración de Aplicabilidad sigue siendo el documento donde la teoría se convierte en compromiso verificable: qué controles aplican, por qué, cómo se implantan y con qué evidencia.

NIST no te pide una Declaración de Aplicabilidad. ISO sí. Y para muchos responsables de cumplimiento, ahí empieza la diferencia entre “tenemos un programa razonable” y “podemos defenderlo delante de un auditor, un cliente o un supervisor”.

El error más caro: mapear controles uno a uno y pensar que el trabajo ya está hecho

Cuando se habla de solapamiento, la tentación es construir una gran matriz: categoría del CSF a la izquierda, control de ISO a la derecha. Útil, sí. Suficiente, no. El problema del mapeo uno a uno es que crea una ilusión de cierre. Parece que, por haber identificado correspondencias, ya has resuelto el problema de duplicidad. En realidad solo has ordenado etiquetas.

Un ejemplo sencillo. La gestión de activos en NIST CSF 2.0 conecta con múltiples piezas de ISO 27001: inventario de información y otros activos asociados, uso aceptable, devolución de activos, clasificación de la información y, según el caso, configuración tecnológica o gestión de vulnerabilidades. Si pretendes hacer una correspondencia lineal, perderás el hecho operativo relevante: en la empresa real, el inventario de activos no vive en un único sitio. Parte está en CMDB, parte en EDR, parte en herramientas cloud, parte en compras, parte en RR. HH. para el ciclo de alta y baja. El control no falla por falta de “mapeo”; falla porque no has definido una fuente de verdad, una cadencia de reconciliación y un dueño claro.

Lo mismo ocurre con terceros. NIST CSF 2.0 dedica mucha atención a la cadena de suministro y al riesgo de dependencias externas. ISO/IEC 27001:2022 y su Anexo A también cubren relaciones con proveedores, requisitos contractuales, monitorización y seguridad en servicios de nube o externalizados. Pero si trabajas en banca, seguros o pagos, la conversación ya no termina ahí. DORA art. 28 obliga a gestionar el riesgo derivado de terceros proveedores de servicios TIC con un marco específico; y el art. 30 exige que los acuerdos contractuales cubran elementos concretos, entre ellos descripción de funciones, lugares de tratamiento, disponibilidad, integridad, acceso, recuperación y derechos de auditoría e inspección. Si tu matriz NIST-ISO no aterriza en cláusulas contractuales y evidencias de due diligence, has construido una tabla bonita y un control mediocre.

El mapeo útil, por tanto, no es solo control contra control. Debe hacerse en tres capas:

1. Outcome: qué resultado de seguridad o resiliencia quieres lograr.
2. Control: qué medidas organizativas, técnicas, físicas o de personas sostienen ese resultado.
3. Evidencia: qué documentos, registros, logs, tickets, aprobaciones o métricas demuestran que el control existe y funciona.

Si falta la tercera capa, duplicarás trabajo porque cada auditoría te pedirá reconstruir pruebas desde cero. Eso sí que es un deporte corporativo bastante absurdo.

Cómo repartir papeles: NIST para priorizar, ISO para demostrar

La manera más eficiente de usar ambos marcos es asignarles un papel distinto dentro del mismo programa.

NIST CSF 2.0 funciona especialmente bien para cuatro tareas. La primera, traducir ciberseguridad a riesgo de negocio. La segunda, priorizar mejoras por capacidades y resultados, no por familias de controles. La tercera, estructurar conversaciones con dirección y con áreas no técnicas. La cuarta, comparar el estado actual y el estado objetivo sin entrar desde el minuto uno en la jerga de certificación.

ISO 27001 funciona mejor para otras cuatro. Una, formalizar el alcance y el contexto del sistema. Dos, asignar roles y responsabilidades que sobrevivan a los cambios de organigrama. Tres, documentar la evaluación y tratamiento del riesgo con trazabilidad. Cuatro, sostener auditoría interna, revisión por la dirección y mejora continua. Si tu empresa necesita certificarse, además, ISO es la vía natural.

En la práctica, esto significa algo muy concreto: no construyas dos evaluaciones de riesgo separadas. Usa una metodología única de riesgo y expresa sus resultados en ambos idiomas. El registro de riesgos puede mapearse a categorías de NIST para la conversación ejecutiva y a objetivos/controls de ISO para la implantación y auditoría. El mismo hallazgo, dos vistas. No dos programas.

Ejemplo operativo: descubres que no existe una segmentación robusta entre entornos de usuario final y sistemas críticos. En NIST CSF 2.0, eso toca resultados de protección de la arquitectura, control de acceso y resiliencia operativa. En ISO 27001:2022, el tratamiento puede relacionarse con controles tecnológicos sobre gestión de identidades, privilegios, seguridad de redes, separación de entornos, monitorización y configuración segura. Bajo NIS2 art. 21, entra de lleno en medidas para prevenir y minimizar el impacto de incidentes, incluyendo seguridad de redes y sistemas de información. Bajo RGPD art. 32, si hay datos personales en juego, afecta a la capacidad de garantizar confidencialidad, integridad, disponibilidad y resiliencia. El trabajo real es uno: diseñar y desplegar segmentación, revisar accesos, registrar excepciones, probar eficacia y dejar evidencia. Lo demás son ángulos de lectura.

La función Govern de NIST 2.0 acerca el marco a Europa más de lo que parece

Muchos equipos europeos veían NIST CSF como un marco útil pero algo volcado hacia lo técnico y operativo. La versión 2.0 corrige parte de esa percepción. La función Govern encaja mejor con la lógica regulatoria europea, que rara vez separa ciberseguridad de gobierno corporativo.

NIS2 es el ejemplo más evidente. El artículo 20 hace responsables a los órganos de dirección de aprobar las medidas de gestión de riesgos de ciberseguridad, supervisar su aplicación y seguir formación. No es un detalle ornamental. Es la forma en que el legislador europeo intenta evitar el viejo truco de tratar la ciberseguridad como un asunto encerrado en un sótano técnico. La función Govern del CSF da un lenguaje razonable para llevar esa responsabilidad al consejo.

DORA va por la misma senda, aunque con más densidad sectorial. Los artículos 5 a 16 exigen un marco interno de gestión del riesgo TIC, estrategia de resiliencia operacional digital, roles claros, clasificación de funciones, protección y prevención, detección, respuesta, recuperación y aprendizaje posterior. Si comparas esto con la lógica de NIST 2.0, la cercanía es obvia. Si lo comparas con ISO 27001, también. La diferencia es que DORA convierte muchas de esas buenas prácticas en obligación supervisable para entidades financieras. Lo voluntario deja de ser tan voluntario cuando llega el supervisor.

Incluso para empresas fuera de finanzas, el encaje regulatorio existe. RGPD art. 24 y art. 32 obligan al responsable a aplicar medidas apropiadas y poder demostrar que el tratamiento es conforme, en función del riesgo. Esa idea de proporcionalidad y demostrabilidad casa bastante bien con un enfoque combinado NIST-ISO: NIST te ayuda a explicar el riesgo y el outcome; ISO te ayuda a demostrar consistencia en las medidas seleccionadas.

Un mapeo sensato no empieza por el Anexo A, sino por el alcance y los procesos

Si quieres evitar duplicidad de verdad, empieza antes de llegar a los controles. Empieza por cuatro preguntas incómodas.

Primera: ¿el alcance del ISMS coincide con el alcance real del programa de ciberseguridad? En muchas compañías, no. El ISMS cubre una unidad, un producto o una geografía concreta, mientras que el SOC, la gestión de vulnerabilidades o IAM operan de forma corporativa. Eso genera pruebas partidas y excepciones mal explicadas. Si el alcance formal de ISO es más estrecho que la realidad operativa, el mapeo con NIST debe dejarlo negro sobre blanco. No todo control corporativo será evidencia válida para todo alcance certificado, y más vale descubrirlo antes que durante la auditoría.

Segunda: ¿la taxonomía de activos es la misma en ambos mundos? NIST habla con soltura de resultados relacionados con activos, datos, tecnologías, servicios y cadena de suministro. ISO exige identificar activos relevantes para la información y su tratamiento. Si tu inventario distingue “aplicación”, “servicio”, “dataset”, “proveedor”, “entorno” y “proceso de negocio” de forma inconsistente entre equipos, el mapeo se romperá en operaciones, no en el papel.

Tercera: ¿la evaluación de riesgos se conecta con decisiones de tratamiento concretas? ISO 27001 no te pide una teoría elegante del riesgo; te pide un proceso definido, criterios, resultados y tratamiento. NIST CSF 2.0 es muy bueno para conversar sobre prioridades, pero si la salida no termina en decisiones trazables —aceptar, reducir, transferir o evitar— no servirá para auditoría ni para reguladores.

Cuarta: ¿quién mantiene las evidencias? Esta pregunta parece menor hasta que llega una auditoría o una inspección. Un SIEM puede mostrar eventos de detección. Un sistema IAM puede enseñar altas y bajas. Un gestor de tickets puede probar remediación de vulnerabilidades. Un repositorio documental puede contener políticas aprobadas. Pero alguien debe ser dueño de cada evidencia, con una frecuencia de revisión definida. Si nadie lo es, acabarás persiguiendo pantallazos. El pantallazo de última hora: piedra angular de demasiados programas de compliance.

Donde más se gana evitando trabajo doble

No todas las áreas ofrecen el mismo ahorro cuando se integran NIST e ISO. Hay cinco donde el retorno es especialmente alto.

1. Gobierno, políticas y roles

La nueva función Govern del CSF y las cláusulas 4, 5 y 6 de ISO 27001 se solapan de forma muy clara. Un único paquete bien diseñado puede cubrir política de seguridad, objetivos, apetito o criterios de riesgo, responsabilidades, segregación de funciones, reporting a dirección y revisión periódica. La clave está en no redactar una política “para ISO” y otra narrativa “para NIST”. Haz una sola arquitectura documental con distintos niveles: política marco, estándares, procedimientos y métricas.

Si además estás en el perímetro de NIS2 o DORA, incluye desde el diseño referencias a supervisión del órgano de dirección, escalado de incidentes y dependencia de terceros. Así evitas reabrir documentos cuando legal llame con prisa.

2. Inventario de activos y clasificación

La mayoría de organizaciones subestiman esta parte porque parece poco glamurosa. Error clásico. Sin inventario fiable no hay gestión de vulnerabilidades seria, ni detección contextual, ni priorización correcta de backups, ni reporting creíble a dirección. En ISO 27001:2022, varios controles organizativos y tecnológicos descansan sobre saber qué activos existen y quién los usa o administra. En NIST CSF 2.0, múltiples categorías dependen del conocimiento de activos, datos, software, plataformas y servicios externos.

La forma de no duplicar es diseñar un modelo de datos único para activos críticos, con atributos mínimos obligatorios: propietario de negocio, custodio técnico, clasificación de información, criticidad, dependencia de proveedor, exposición a internet, requisito regulatorio aplicable y estado de respaldo/recuperación. Con eso alimentas riesgo, operación, auditoría y cumplimiento. Sin eso, generarás cuatro inventarios y confiarás en ninguno.

3. Gestión de terceros

Aquí convergen ISO, NIST, RGPD, NIS2 y DORA. ISO 27001 exige gestionar seguridad en relaciones con proveedores. NIST 2.0 refuerza cadena de suministro. RGPD art. 28 impone requisitos concretos para encargados del tratamiento y su contrato. DORA art. 28 y art. 30 endurecen aún más el juego para el sector financiero. Si cada régimen produce su propia due diligence, su propia plantilla contractual y su propio scoring, el coste se dispara.

La salida razonable es una evaluación unificada por tiers de criticidad. Un proveedor SaaS que procese datos personales, soporte un proceso crítico y aloje carga sensible no debería pasar por tres cuestionarios incoherentes. Debería pasar por un único proceso que recoja seguridad, privacidad, resiliencia, continuidad, subcontratación, localización del servicio, cifrado, autenticación, logging, recuperación, notificación de incidentes y derechos de auditoría. Luego mapeas esas respuestas a controles ISO, outcomes NIST y cláusulas legales aplicables.

Un detalle práctico que muchas empresas pasan por alto: el requisito de notificación contractual de incidentes de un proveedor no debería alinearse solo con “sin demora indebida”. Si estás sujeto a RGPD art. 33 y debes valorar una notificación en 72 horas, o a NIS2 art. 23 con alerta temprana en 24 horas y notificación de incidente en 72 horas, o a DORA con su régimen sectorial, la ventana contractual con proveedores tiene que dejarte margen real para analizar y escalar. Si el proveedor se reserva cinco días hábiles para “investigar internamente”, tu cumplimiento ya nace cojo.

4. Detección, respuesta y notificación

NIST CSF siempre ha brillado aquí porque ordena bien la secuencia detectar-responder-recuperar. ISO 27001 cubre la necesidad de preparar y gestionar incidentes, pero muchas organizaciones usan NIST como marco más legible para playbooks y capacidad operativa. No hay problema. Lo que no conviene es documentar una respuesta “NIST” en un lado y un procedimiento “ISO” en otro con ligeras diferencias de criterio. Eso genera fricción justo cuando no te la puedes permitir.

Diseña un único marco de gestión de incidentes con taxonomía común, umbrales de severidad, tiempos de escalado, criterios de implicación legal y rutas de comunicación. Después mapea. Si el incidente afecta a datos personales, activas valoración bajo RGPD art. 33 y, si procede, art. 34. Si afecta a servicios esenciales o importantes, miras NIS2 art. 23. Si eres entidad financiera bajo DORA, aplicas su régimen de reporte de incidentes graves relacionados con TIC. El playbook es uno; los gatillos regulatorios, varios.

5. Métricas y revisión

Una razón habitual para la duplicidad es que seguridad mide una cosa, riesgo otra y compliance una tercera. NIST CSF 2.0 permite definir perfiles actuales y objetivo; ISO exige evaluación del desempeño y mejora continua. Junta ambas lógicas. No midas “número de controles implementados” si lo que interesa es reducción de exposición o capacidad operativa. Tampoco midas solo outcomes difusos si luego no puedes enseñar evidencia.

Un cuadro de mando útil combina métricas de gestión y de efectividad: cobertura de MFA en cuentas privilegiadas y de usuario, tiempo medio de remediación de vulnerabilidades críticas, porcentaje de activos críticos inventariados con propietario asignado, éxito de restauración en pruebas de backup, porcentaje de proveedores críticos con evaluación vigente, tiempo de contención de incidentes de severidad alta y desviaciones abiertas fuera de plazo. Esas métricas sirven para NIST, para ISO y, bien encajadas, para conversaciones con dirección bajo NIS2 o DORA.

Qué controles de ISO 27001 suelen absorber mejor las categorías de NIST

No hace falta reproducir una matriz entera para entender el patrón. Lo útil es ver cómo se agrupan las correspondencias más productivas.

Las categorías de Govern de NIST suelen apoyarse sobre las cláusulas 4 a 10 de ISO 27001 y sobre controles organizativos del Anexo A relacionados con políticas, roles, segregación de funciones, gestión de proyectos, gestión de activos, clasificación, gestión de proveedores, continuidad y cumplimiento. Es el terreno donde más se gana integrando porque mezcla gobierno y control.

Las categorías de Identify se llevan bien con inventario de activos, clasificación de información, análisis de impacto, evaluación de riesgos, dependencias de terceros y gestión de arquitectura. Aquí la clave es la coherencia semántica: que “activo crítico” signifique lo mismo para seguridad, continuidad y negocio.

Protect absorbe buena parte de los controles tecnológicos y de personas: identidad y acceso, autenticación, privilegios, hardening, malware, cifrado, DLP, desarrollo seguro, seguridad de endpoints, teletrabajo, formación y uso aceptable. Es la parte más poblada y donde más fácil es caer en una implementación descoordinada si el ownership está repartido entre demasiados equipos.

Detect conecta con logging, monitorización, detección de anomalías, correlación de eventos, threat intelligence y supervisión de entornos. ISO 27001 permite cubrirlo, pero NIST suele aportar mejor narrativa operativa.

Respond y Recover se apoyan en procedimientos de respuesta, análisis, comunicación, lecciones aprendidas, continuidad, backup, restauración y mejora. En entornos regulados, aquí se cruzan con notificación de incidentes y pruebas periódicas. Si haces tabletop exercises, simulacros técnicos o tests de restauración, estás generando oro probatorio siempre que los dejes documentados y con acciones correctivas cerradas.

Cómo construir una única biblioteca de evidencias

El ahorro real no aparece cuando haces un mapa bonito en Excel. Aparece cuando dejas de pedir el mismo documento diez veces a diez personas distintas. Para eso necesitas una biblioteca de evidencias diseñada de forma transversal.

La unidad mínima no debe ser “control ISO” ni “subcategoría NIST”, sino afirmación verificable. Por ejemplo: “todas las cuentas privilegiadas están protegidas con MFA”. Esa afirmación puede servir para un control tecnológico de ISO, para una categoría de protección de NIST, para demostrar adecuación bajo RGPD art. 32 y para justificar una medida de reducción de riesgo bajo NIS2 art. 21. La evidencia asociada puede incluir política aprobada, configuración técnica, export de cobertura, listado de excepciones aprobadas y revisión periódica.

Otro ejemplo: “los proveedores críticos con acceso a información o sistemas son evaluados antes de la contratación y revisados al menos anualmente”. Esa afirmación conecta con NIST, con ISO, con RGPD art. 28 cuando hay tratamiento por cuenta de tercero y, en finanzas, con DORA art. 28 y 30. La evidencia puede ser procedimiento, cuestionario, scoring, contrato con cláusulas específicas, revisión anual y registro de incidencias del proveedor.

Si estructuras tu repositorio alrededor de afirmaciones, propietarios, frecuencia de revisión y fuentes de evidencia, luego podrás reutilizarlo para auditorías ISO, evaluaciones NIST, cuestionarios de clientes, due diligence de M&A y requerimientos regulatorios. Eso sí es no duplicar.

Checklist de evidencias para auditoría

Esta pieza sí justifica una checklist, porque estamos hablando de controles auditables y de cómo no generar trabajo doble. Si tu programa usa NIST CSF 2.0 e ISO 27001 a la vez, estas evidencias deberían existir en un formato trazable y reutilizable.

• Alcance del ISMS y contexto: documento de alcance, partes interesadas, procesos incluidos, interfaces con servicios corporativos compartidos.
• Metodología de riesgo: criterios de probabilidad/impacto, apetito o umbrales, registro de riesgos, decisiones de tratamiento y aprobaciones.
• Declaración de Aplicabilidad: controles aplicables/no aplicables del Anexo A de ISO 27001:2022, justificación y referencia a evidencias.
• Mapa NIST CSF 2.0: perfil actual/objetivo o, al menos, correspondencia entre categorías prioritarias, riesgos y controles implantados.
• Gobierno: políticas aprobadas, comité o foro de seguridad, actas, reporting a dirección, asignación de roles y responsabilidades.
• Inventario de activos: listado de activos críticos con propietario, clasificación, dependencias y estado de protección.
• IAM y privilegios: estándar de acceso, evidencia de MFA, revisiones periódicas de privilegios, altas/bajas y segregación de funciones.
• Gestión de vulnerabilidades: política, escaneos, priorización, SLAs internos, tickets de remediación y excepciones aprobadas.
• Logging y monitorización: fuentes de logs, casos de uso de detección, retención, revisiones y cobertura sobre activos críticos.
• Respuesta a incidentes: procedimiento, playbooks, registro de incidentes, escalado legal, post-mortems y acciones correctivas.
• Backups y recuperación: política, periodicidad, cifrado, pruebas de restauración y resultados.
• Proveedores: inventario de terceros críticos, evaluaciones, contratos, cláusulas de seguridad y revisiones periódicas.
• Formación y concienciación: plan, evidencias de asistencia, campañas de phishing si existen y seguimiento de reincidencias.
• Auditoría interna y revisión por la dirección: informes, no conformidades, acciones correctivas y seguimiento.

Si varias de estas evidencias solo pueden obtenerse a mano, una vez al año y con sudor administrativo, no tienes un problema de auditoría. Tienes un problema de diseño del sistema.

Implicaciones para entidades financieras españolas

Para bancos, aseguradoras, entidades de pago, gestoras y otros sujetos de DORA en España, combinar NIST CSF 2.0 e ISO 27001 tiene sentido, pero con un matiz clave: DORA no se conforma con “buenas prácticas razonables”. Pide consistencia operacional, capacidad de prueba y gestión formal de terceros TIC. Y eso desplaza el centro de gravedad hacia evidencias, contratos y testing.

En el mercado español, muchas entidades ya partían de ISO 27001 para determinadas unidades o servicios, mientras que los equipos de ciberseguridad usaban NIST o marcos internos para madurez y operación. DORA obliga a soldar esas capas. El artículo 11, por ejemplo, exige marcos de respuesta y recuperación de TIC. Los artículos 24 a 27 cubren pruebas de resiliencia operativa digital, incluyendo, para ciertas entidades, pruebas avanzadas basadas en amenazas. No basta con decir que existe capacidad de respuesta; hay que demostrarla y probarla.

Esto tiene consecuencias muy prácticas. Si tu entidad usa NIST para estructurar detección y respuesta, perfecto. Pero la evidencia debe ser reutilizable para auditoría interna, segunda línea, supervisor y, donde aplique, certificaciones existentes. Lo mismo con terceros: una due diligence “ligera” que servía hace tres años puede quedarse corta frente a DORA art. 30 si no cubre subcontratación en cadena, localización del tratamiento, acceso, recuperación y derechos de inspección.

Además, NIS2 y DORA no viven en compartimentos estancos. Algunas entidades financieras relevantes podrán tener obligaciones cruzadas o, como mínimo, expectativas de supervisión alineadas con ambas normas en materia de gobierno, gestión del riesgo y notificación. Si tu arquitectura documental ya traduce outcomes NIST a controles ISO y a obligaciones DORA/NIS2, llegarás mejor preparado a esa conversación. Si no, prepárate para una temporada larga de matrices retrospectivas.

Objeción habitual: “si ya tengo ISO 27001, NIST no me hace falta”

Es una objeción entendible. También suele ser miope.

Si tu ISMS está maduro, auditado y realmente usado para gestionar decisiones, puedes vivir sin NIST CSF 2.0. Nadie lo impide. Pero muchas organizaciones con certificación ISO tienen un problema menos elegante: el sistema existe, pasa auditorías, y aun así no ordena bien la priorización técnica ni la conversación ejecutiva. Hay políticas impecables y una visión borrosa de las capacidades reales frente a ransomware, dependencias cloud, identidad privilegiada o resiliencia de proveedores. NIST ayuda precisamente ahí: baja el debate a resultados y funciones reconocibles por seguridad y negocio.

La objeción inversa también falla: “si ya uso NIST, ISO solo añade burocracia”. A veces sí añade burocracia; casi siempre porque se implanta mal. Pero renunciar a la disciplina de ISO suele salir caro cuando toca demostrar consistencia, revisar cambios, cerrar acciones correctivas o sostener evaluación independiente. En Europa, además, la presión regulatoria va justo en esa dirección: menos promesas generales, más trazabilidad y prueba.

La combinación inteligente no consiste en inflar documentación. Consiste en usar NIST para decidir mejor y ISO para demostrar mejor.

Un enfoque operativo que sí funciona

Si hoy tu organización quiere integrar ambos marcos sin levantar una segunda burocracia, el orden importa.

Empieza por definir una taxonomía única de activos, procesos críticos, datos sensibles y terceros relevantes. Después, revisa tu metodología de riesgo para que produzca salidas utilizables tanto por dirección como por auditoría: riesgo, dueño, tratamiento, plazo, excepción y evidencia. Luego identifica las capacidades clave de NIST CSF 2.0 que más negocio tocan —gobierno, terceros, identidad, detección, recuperación— y enlázalas con controles del Anexo A y con procesos operativos existentes. Solo entonces construye la matriz de correspondencias. Si empiezas por la matriz, convertirás un problema de diseño en un problema de celdas.

El segundo paso es consolidar evidencias. No por control, sino por afirmación verificable y fuente de sistema. Define para cada una el propietario, la frecuencia y la ruta de extracción. Idealmente, mucha evidencia debería generarse desde herramientas fuente: IAM, EDR, SIEM, ticketing, GRC, CMDB, repositorios de contratos o herramientas de terceros. Cuanto menos dependas de documentos manuales, menos sufrirás en cada revisión.

El tercer paso es alinear gobierno. La función Govern de NIST 2.0 te da una oportunidad excelente para limpiar comités, métricas y reporting. Si la dirección recibe veinte indicadores técnicos irrelevantes, no está gobernando nada. Si recibe cinco métricas claras, riesgos priorizados, estado de acciones correctivas, dependencias críticas de terceros y resultados de pruebas de recuperación, la conversación cambia.

El cuarto paso es probar. Simulacros de incidentes, restauraciones, revisiones de acceso, pruebas de proveedores, ejercicios de escalado legal. Lo que no se prueba, en seguridad, suele descubrirse en el peor momento posible. Y lo que se prueba pero no se documenta, para auditoría, casi no existe.

La conclusión incómoda: el problema no son los marcos, es la fragmentación interna

NIST CSF 2.0 e ISO 27001 pueden convivir sin duplicar trabajo. De hecho, se complementan bastante bien. El primero ordena la conversación sobre capacidades y riesgo. El segundo obliga a que esa conversación deje rastro, dueño y mejora continua. El atasco aparece cuando seguridad, riesgo, compliance, privacidad, continuidad y compras operan con taxonomías distintas, evidencias separadas y calendarios incompatibles.

Si algo ha cambiado en 2024 y 2025 no es solo el marco de NIST. Ha cambiado la tolerancia regulatoria a los programas decorativos. NIS2 aprieta sobre gobierno y notificación. DORA aprieta sobre resiliencia, pruebas y terceros. RGPD sigue exigiendo medidas apropiadas y capacidad de demostrarlo. En ese escenario, mantener dos programas paralelos porque uno “es para ciber” y otro “es para auditoría” deja de ser una preferencia metodológica. Empieza a parecerse a una ineficiencia cara.

La buena noticia es que no hace falta rehacerlo todo. Hace falta una decisión de diseño: una sola metodología de riesgo, una sola arquitectura documental, una sola biblioteca de evidencias y dos vistas complementarias. Si tu entidad todavía produce respuestas distintas para la misma pregunta según la haga el auditor, el cliente o el regulador, ya sabes dónde está el trabajo de verdad.

Y no, la solución no es otra hoja Excel.