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

Muchas organizaciones mantienen dos conversaciones paralelas sobre ciberseguridad. En una, el CISO habla de funciones, perfiles y madurez con el NIST Cybersecurity Framework 2.0. En la otra, compliance prepara la Declaración de Aplicabilidad, revisa los controles del anexo A de ISO/IEC 27001:2022 y atiende al auditor. El resultado suele ser una colección de matrices que se parecen demasiado entre sí y explican muy poco sobre el riesgo real.

La solución no consiste en elegir entre ambos marcos. Consiste en asignarles trabajos distintos. NIST CSF 2.0 sirve para describir cómo se gobierna y gestiona el riesgo de ciberseguridad; ISO 27001 exige demostrar que existe un sistema de gestión auditable, con alcance, responsabilidades, evaluación de riesgos, tratamiento y mejora continua. Uno ayuda a dirigir la conversación. El otro convierte esa conversación en un sistema que puede ser examinado.

Aquí está el punto que suele perderse en las presentaciones de consultoría: un mapeo entre el NIST CSF 2.0 y los 93 controles del anexo A de ISO 27001 no prueba que una organización cumpla ISO, ni significa que un control de un marco sea automáticamente equivalente a otro. Solo crea una relación útil entre resultados de ciberseguridad y controles. La evidencia sigue siendo responsabilidad de la empresa.

Dos marcos, dos preguntas diferentes

NIST CSF 2.0, publicado por el National Institute of Standards and Technology en febrero de 2024, organiza los resultados de ciberseguridad en seis funciones: Govern, Identify, Protect, Detect, Respond y Recover. La incorporación de Govern no es un cambio cosmético. Sitúa la estrategia, el apetito de riesgo, las políticas, la supervisión y la cadena de suministro en el mismo nivel que la detección o la recuperación. Es una corrección bastante sensata a años de programas que medían el número de alertas como si el volumen de alertas fuera una estrategia.

El marco permite trabajar con categorías y subcategorías, crear un Current Profile y un Target Profile, y utilizar los Organizational Profiles para describir prioridades según el tipo de organización. También mantiene los cuatro niveles de implementación: Partial, Risk Informed, Repeatable y Adaptive. Estos niveles no son una certificación ni una escala universal de cumplimiento. Describen la madurez y el carácter de la gestión del riesgo, desde prácticas ad hoc hasta una mejora continua basada en aprendizaje y adaptación.

ISO/IEC 27001:2022 responde a otra pregunta: ¿ha establecido la organización un sistema de gestión de seguridad de la información que cumple los requisitos de la norma y trata sus riesgos de forma controlada? Sus cláusulas 4 a 10 cubren el contexto de la organización, el liderazgo, la planificación, el apoyo, la operación, la evaluación del desempeño y la mejora. El anexo A aporta 93 controles de referencia agrupados en cuatro bloques: organizativos, de personas, físicos y tecnológicos.

La diferencia tiene consecuencias prácticas. NIST puede ayudar al comité de riesgos a entender que la dependencia de un proveedor cloud afecta a Govern, Identify y Protect, y que debe probarse también en Respond y Recover. ISO obliga a traducir esa preocupación en elementos verificables: criterios de evaluación de proveedores, responsabilidades contractuales, revisión del riesgo, registros, auditorías y acciones correctivas. NIST estructura el mapa. ISO exige mantener las carreteras.

El error caro: tratar el mapeo como una tabla de equivalencias

Una tabla que coloca una subcategoría de NIST al lado de un control del anexo A es útil para empezar. Se vuelve peligrosa cuando se presenta como prueba de cobertura. Los dos marcos no tienen la misma arquitectura, el mismo propósito ni el mismo lenguaje normativo.

Por ejemplo, la categoría NIST PR.AA sobre identidad, autenticación y control de acceso puede relacionarse con varios controles de ISO 27001:2022, entre ellos el control 5.15 sobre control de acceso, el 5.16 sobre gestión de identidades, el 5.17 sobre información de autenticación y el 8.5 sobre autenticación segura. Pero la relación no dice qué aplicaciones están dentro del alcance, qué cuentas privilegiadas se revisan, con qué frecuencia se recertifican los permisos, qué excepciones existen ni qué evidencia conserva la entidad.

La misma subcategoría de NIST puede requerir varios controles de ISO, procedimientos internos, configuraciones técnicas y registros. Y un control de ISO puede contribuir a varias subcategorías del NIST CSF. El control 5.23, sobre seguridad de la información para el uso de servicios cloud, no se agota en contratar a un proveedor con una certificación. También afecta a la evaluación del servicio, la configuración, la salida, la segregación de responsabilidades y la supervisión continua. Una casilla marcada no sustituye esa cadena de decisiones.

Hay otra trampa: el anexo A no es una lista que deba implantarse íntegramente sin análisis. La organización debe seleccionar los controles necesarios a partir de su evaluación de riesgos, justificar las inclusiones y exclusiones y documentarlo en la Declaración de Aplicabilidad. Un control puede aparecer como no aplicable, pero la exclusión necesita una razón defendible. El mapeo NIST-ISO puede señalar una laguna; no puede decidir por sí solo si ese control es necesario.

La pregunta correcta no es qué control de ISO corresponde a cada subcategoría de NIST. Es esta: ¿qué resultado de ciberseguridad queremos conseguir, qué riesgo lo justifica, qué control lo trata, quién es responsable y qué evidencia demuestra que funciona?

Cómo construir un mapa que sirva para algo

El mapa debe ser una capa de traducción, no el programa de seguridad entero. Una estructura operativa razonable contiene, como mínimo, seis campos: resultado NIST, riesgo asociado, control o controles ISO relacionados, propietario, evidencia esperada y estado de efectividad. Añadiría un séptimo: obligación regulatoria conectada. En una entidad financiera europea, el mismo tratamiento de riesgos puede alimentar NIST, ISO, DORA y, según el sector, NIS2 o el artículo 32 del RGPD.

El primer paso es fijar el alcance. ISO 27001 no se certifica sobre una abstracción llamada empresa; se certifica sobre un sistema de gestión con límites concretos. Puede abarcar la plataforma de pagos, el desarrollo de software, una unidad de banca digital o todos los servicios corporativos. El perfil NIST debe usar el mismo perímetro si se pretende comparar resultados. Si el Current Profile incluye el grupo entero y el alcance ISO solo cubre una filial, cualquier conclusión sobre cobertura será engañosa.

El segundo paso es describir el resultado deseado en lenguaje operativo. Decir que la organización quiere mejorar Detect es demasiado amplio. Una formulación útil sería: los eventos relevantes de los sistemas incluidos en el alcance se recopilan, correlacionan y escalan con criterios documentados; las fuentes críticas tienen propietario; y la ausencia de telemetría se identifica como una excepción. Entonces el mapeo puede conectar, entre otros, las subcategorías DE.CM de monitorización continua y DE.AE de análisis de eventos con controles ISO como el 8.15 sobre logging y el 8.16 sobre actividades de monitorización.

El tercer paso es enlazar cada resultado con riesgos concretos. Para una plataforma de pagos, la falta de logs en una API crítica puede afectar a la confidencialidad, integridad y disponibilidad, pero también a la capacidad de investigar una operación fraudulenta. El tratamiento no será simplemente habilitar registros. Incluirá retención, integridad, acceso restringido, sincronización temporal, revisión de alertas y pruebas de recuperación. El mapeo debe reflejar esa realidad o será una pieza decorativa.

El cuarto paso es registrar la evidencia antes de declarar el control implantado. Para el control ISO 8.15, la evidencia puede incluir la política de logging, el inventario de fuentes, configuraciones de SIEM, una muestra de logs, reglas de retención, resultados de una revisión y tickets que prueben la corrección de fallos. Para NIST, esa misma evidencia demuestra progreso hacia el resultado DE.CM. No hace falta fabricar dos expedientes porque los nombres sean distintos.

Ejemplo: acceso privilegiado en una entidad financiera

Supongamos que una entidad detecta que los administradores de una base de datos de pagos utilizan cuentas nominales, pero que la revisión trimestral de privilegios no cubre a un proveedor externo con acceso de soporte. El Current Profile puede mostrar una cobertura parcial en PR.AA. El riesgo es claro: una identidad privilegiada no revisada podría alterar datos o dificultar la atribución de una operación.

La respuesta no consiste en marcar como cumplidos los controles 5.15, 5.16, 5.18 y 8.2 de ISO porque existe una política de acceso. El análisis debe comprobar si las cuentas están inventariadas, si se aplica mínimo privilegio, si el acceso del proveedor es temporal, si hay autenticación multifactor, si las sesiones se registran, si la revisión incluye excepciones y si las revocaciones se ejecutan dentro del plazo definido. La evidencia puede revelar que el diseño es correcto pero la operación falla.

En este caso, el Target Profile debería describir un resultado verificable: todas las identidades privilegiadas del alcance están identificadas, autenticadas con controles reforzados, sujetas a aprobación y revisadas con una frecuencia basada en riesgo; el acceso de terceros se concede por tiempo limitado y las sesiones críticas dejan trazabilidad. El mapa con ISO ayuda a localizar controles relacionados, pero la decisión sobre el nivel objetivo pertenece a la dirección y al propietario del riesgo.

La pieza que ISO aporta y NIST no pretende sustituir

El NIST CSF 2.0 es deliberadamente flexible. Esa flexibilidad es su fortaleza para el gobierno y su debilidad si alguien busca un expediente de auditoría listo para entregar. ISO 27001 aporta disciplina institucional: política aprobada, responsabilidades, competencia, comunicación, control documental, evaluación del desempeño, auditoría interna, revisión por la dirección y tratamiento de no conformidades.

La cláusula 6.1 de ISO exige abordar riesgos y oportunidades del sistema de gestión. La organización debe definir un proceso de evaluación de riesgos de seguridad de la información y un proceso de tratamiento. La cláusula 8.2 exige realizar evaluaciones de riesgos a intervalos planificados y cuando se produzcan cambios significativos. La cláusula 9.1 introduce el seguimiento, medición, análisis y evaluación. Estas obligaciones son las que convierten un perfil NIST en un ciclo de gestión en vez de en una fotografía amable para la presentación anual.

La cláusula 9.2 sobre auditoría interna y la 9.3 sobre revisión por la dirección también cambian la conversación. El CISO no debería limitarse a enseñar que el porcentaje de subcategorías cubiertas ha subido. Debe explicar qué riesgos siguen abiertos, qué excepciones se han aceptado, si los controles funcionan y qué recursos necesita la organización. Una mejora del color rojo al ámbar en una matriz no es una mejora de seguridad.

La Declaración de Aplicabilidad cumple una función especialmente útil en el modelo combinado. Puede incorporar la relación entre controles seleccionados, riesgos tratados, resultados NIST y obligaciones regulatorias. Pero debe conservar la justificación de cada inclusión o exclusión. Si una subcategoría NIST se cubre mediante un control alternativo o una medida técnica no descrita literalmente en el anexo A, esa relación debe estar explicada y respaldada por evidencia.

Qué cambia para DORA, NIS2 y RGPD

Para una entidad financiera europea, la combinación adquiere valor porque los supervisores no examinan marcos aislados, sino la capacidad real de gobernar el riesgo tecnológico. DORA es aplicable desde el 17 de enero de 2025 y su artículo 6 exige que las entidades dispongan de un marco de gestión del riesgo de las TIC sólido, completo y bien documentado. El artículo 5 sitúa la responsabilidad en el órgano de dirección. No basta con que el equipo de seguridad tenga un perfil NIST bien diseñado si el consejo no recibe información sobre riesgos, excepciones y capacidad de recuperación.

El artículo 11 de DORA exige políticas y procedimientos de respaldo, restauración y recuperación. En un mapa NIST, la conexión natural aparece en Recover, especialmente en las categorías RC.RP y RC.CO, pero el análisis debe ir más lejos: objetivos de tiempo y punto de recuperación, dependencias de terceros, pruebas, criterios de retorno a la operación normal y comunicación interna y externa. El control ISO 8.13 sobre copias de seguridad o el 5.30 sobre preparación de las TIC para la continuidad del negocio pueden apoyar el tratamiento, pero no reemplazan los requisitos específicos de DORA.

El artículo 28 de DORA, dedicado a la gestión del riesgo de terceros proveedores de servicios de TIC, convierte el inventario de proveedores y las cláusulas contractuales en una cuestión de gobierno, no solo de compras. El control ISO 5.19 sobre relaciones con proveedores, el 5.20 sobre seguridad en acuerdos con proveedores, el 5.21 sobre la cadena de suministro de TIC y el 5.22 sobre seguimiento, revisión y gestión del cambio pueden relacionarse con Govern e Identify. Sin embargo, el cumplimiento de DORA requiere también abordar derechos de auditoría, subcontratación, salida, concentración y, cuando proceda, la supervisión de proveedores críticos por las autoridades europeas.

NIS2, por su parte, establece en el artículo 21 medidas de gestión de riesgos de ciberseguridad para entidades esenciales e importantes. Entre ellas figuran el análisis de riesgos, la gestión de incidentes, la continuidad, la seguridad de la cadena de suministro, la evaluación de la eficacia de las medidas, la formación, la criptografía y el control de accesos. Un perfil NIST es una forma eficaz de ordenar ese conjunto, pero la entidad debe revisar la transposición nacional aplicable y no asumir que el uso del marco estadounidense satisface automáticamente el derecho nacional.

El artículo 23 de NIS2 introduce obligaciones de notificación de incidentes significativos, con una alerta temprana en un plazo de 24 horas desde que se tenga conocimiento del incidente, una notificación del incidente en 72 horas y un informe final, salvo las condiciones y matices previstos en la propia directiva y en las medidas nacionales de aplicación. El mapa debe conectar Detect y Respond con el procedimiento de clasificación, los responsables de decidir la notificación, las plantillas, los canales y la evidencia temporal. Tener un SIEM no garantiza que alguien sepa cuándo empieza a correr el reloj.

El RGPD añade otra capa cuando el incidente afecta a datos personales. Su artículo 32 exige medidas técnicas y organizativas apropiadas al riesgo; el artículo 33 fija, cuando procede, la notificación a la autoridad de control sin dilación indebida y, como máximo, en 72 horas desde que se tenga constancia de la violación. La coincidencia temporal con NIS2 puede ser útil, pero no deben fusionarse las decisiones sin análisis: los umbrales, destinatarios y contenidos no son idénticos. Un procedimiento común puede tener ramas jurídicas distintas.

El mapeo no elimina las zonas grises

Una objeción razonable sostiene que mantener NIST, ISO, DORA, NIS2 y RGPD en una misma arquitectura puede generar más burocracia que seguridad. La objeción es válida. Las organizaciones que crean un control separado para cada obligación terminan midiendo el trabajo administrativo: número de políticas, reuniones y columnas de Excel. Eso no es resiliencia; es entropía con membrete.

La respuesta no es abandonar los marcos, sino establecer una jerarquía. La política corporativa y el modelo de riesgo deben ser comunes. Los controles técnicos deben tener un propietario único. La evidencia debe almacenarse una vez, con metadatos suficientes para reutilizarla. Las obligaciones regulatorias deben vincularse al control y no convertirse en proyectos independientes salvo que exista una exigencia material diferente. La matriz debe mostrar diferencias, no ocultarlas.

También hay que aceptar que algunas áreas no se resuelven con un mapeo. DORA introduce exigencias propias sobre pruebas de resiliencia operativa digital, incluidos los test de penetración basados en amenazas para determinadas entidades. ISO y NIST pueden ayudar a gobernar el proceso, definir el alcance y registrar la remediación, pero no crean por sí mismos la obligación ni determinan quién debe someterse a una prueba avanzada. Del mismo modo, la certificación ISO no demuestra que una entidad haya cumplido cada requisito de notificación de NIS2.

La madurez del mapa se ve en cómo trata las excepciones. Un resultado NIST puede estar parcialmente alcanzado porque un sistema legado no soporta autenticación multifactor. ISO puede reflejar un control implantado de forma compensatoria. DORA puede exigir que el riesgo sea aceptado por el nivel de dirección apropiado. El registro debe conservar la causa, el propietario, la fecha de revisión, la medida compensatoria y el criterio de cierre. Si solo aparece una celda amarilla, el riesgo ha sido maquillado, no gestionado.

Cómo medir si la integración funciona

Las métricas deben unir cobertura, efectividad y exposición. El porcentaje de controles con una política aprobada mide poco. Es más útil conocer qué proporción de activos críticos está cubierta por telemetría validada, qué porcentaje de cuentas privilegiadas se revisó dentro del plazo, cuánto tiempo tardan en revocarse accesos de terceros y cuántos sistemas críticos han probado su recuperación dentro del objetivo establecido.

Para la función Respond, una entidad puede medir la mediana de tiempo desde la detección hasta la clasificación, el porcentaje de incidentes con análisis de causa raíz y la proporción de ejercicios que generaron acciones cerradas. Para Recover, puede medir el porcentaje de servicios críticos que completaron una restauración técnica, no solo una revisión documental. Para Govern, puede observar cuántos riesgos tecnológicos relevantes se presentan al órgano de dirección con decisión explícita sobre aceptación, mitigación o transferencia.

Estas métricas deben conservar su relación con el riesgo. Reducir el tiempo medio de respuesta de 20 a 10 minutos es una mejora aparente si la organización solo mide alertas de baja prioridad. La métrica debe indicar qué población cubre, qué excepciones quedan fuera y qué impacto tiene el resultado sobre los activos críticos. Un auditor puede aceptar un indicador bien definido; un atacante no se impresionará con él.

Checklist de evidencias para auditoría y supervisión

Una integración NIST-ISO defendible puede organizar la evidencia en cinco paquetes. No se trata de acumular documentos, sino de permitir que una tercera persona reconstruya la decisión y compruebe la operación.

• Gobierno y alcance: alcance del SGSI, inventario de activos y servicios críticos, política aprobada, roles, comité responsable, apetito de riesgo y actas donde se hayan aceptado excepciones relevantes. Aquí deben verse las conexiones con ISO 27001, cláusulas 4, 5 y 6, y con DORA, artículos 5 y 6.
• Riesgo y tratamiento: metodología, registro de riesgos, criterios de impacto y probabilidad, decisiones de tratamiento, controles seleccionados y Declaración de Aplicabilidad. Cada relación NIST-ISO debe explicar qué riesgo trata y qué resultado pretende alcanzar.
• Operación de controles: configuraciones, revisiones de accesos, resultados de vulnerabilidades, registros, evidencias de backup, ejercicios de phishing, formación, evaluaciones de proveedores y tickets de remediación. La fecha y el propietario importan tanto como el documento.
• Detección, respuesta y recuperación: casos de uso del SIEM, procedimientos de escalado, cronología de incidentes, decisiones de notificación, pruebas de restauración, resultados de simulacros y acciones posteriores. Aquí deben trazarse las obligaciones de DORA art. 11, NIS2 art. 23 y RGPD art. 33 cuando sean aplicables.
• Evaluación y mejora: auditorías internas, revisiones por la dirección, indicadores, no conformidades, análisis de causa raíz y comprobación de la eficacia de las acciones. El mapa debe mostrar cómo cambia el Target Profile después de un incidente o una prueba, no permanecer congelado hasta la siguiente auditoría.

Esta estructura también evita un problema habitual: entregar al auditor una política que describe un control y ningún rastro de que se haya ejecutado. ISO distingue entre diseñar un sistema y operarlo; el NIST CSF ayuda a señalar el resultado esperado, pero la prueba sigue estando en los registros, las decisiones y los resultados.

Qué debería hacer ahora un CISO

El primer movimiento no es comprar una nueva plataforma de GRC. Es seleccionar un flujo de riesgo importante y seguirlo de extremo a extremo. Puede ser la gestión de identidades privilegiadas, la recuperación de un servicio de pagos, la incorporación de un proveedor cloud o la respuesta ante una fuga de datos. Si el mapa no funciona en ese caso concreto, tampoco funcionará después de cargar 500 controles.

Después conviene reconciliar los inventarios. El inventario de activos de NIST, el alcance del SGSI, el registro de servicios críticos de DORA, el inventario de proveedores y el registro de tratamientos del RGPD suelen vivir en sistemas distintos. No hace falta que todos sean idénticos, pero sí que exista una relación explícita. Un servicio crítico que no tiene propietario, un proveedor que no aparece en el análisis de concentración o un tratamiento de datos que carece de medidas de seguridad son fallos de gobierno antes que fallos de herramienta.

El Target Profile debe aprobarse con participación del negocio. Si el CISO fija objetivos sin presupuesto ni dueño, ha redactado una lista de deseos. Si el consejo aprueba apetito de riesgo sin conocer las dependencias técnicas, ha aprobado una abstracción. El perfil objetivo debe expresar prioridades, umbrales de aceptación y decisiones de inversión, y debe actualizarse cuando cambien los servicios, las amenazas, los proveedores o las obligaciones legales.

Finalmente, hay que revisar el mapa con una frecuencia ligada al riesgo, no al calendario de la auditoría. Un cambio de proveedor, una migración cloud, una adquisición, un incidente grave o una nueva obligación nacional puede invalidar las relaciones existentes. El NIST CSF 2.0 es útil precisamente porque permite reordenar prioridades sin reconstruir todo el sistema. ISO aporta el mecanismo para documentar el cambio y comprobar que se ha implantado.

La conclusión incómoda: menos matrices, más decisiones

NIST CSF 2.0 e ISO 27001:2022 funcionan mejor juntos cuando dejan de competir por ser el marco principal. NIST ofrece una gramática para hablar de resultados, riesgos, perfiles y madurez. ISO aporta el sistema de gestión, la disciplina documental y la posibilidad de someter el conjunto a una auditoría independiente. El mapeo entre ambos reduce duplicidades solo si conecta cada resultado con un riesgo, un propietario, un control y una evidencia.

Para los CISOs europeos, el valor adicional está en usar esa misma arquitectura para explicar DORA, NIS2 y RGPD sin prometer una equivalencia que no existe. DORA art. 6 no se cumple por tener un perfil NIST; NIS2 art. 23 no se satisface con un procedimiento de incidentes genérico; el RGPD art. 32 no queda demostrado por un certificado ISO. Pero los tres regímenes pueden alimentarse de un sistema de control coherente.

La prueba final es sencilla. Pregunta por un riesgo concreto y observa la respuesta: ¿se puede identificar el activo, el propietario, el control, la obligación aplicable, la evidencia más reciente, la excepción vigente y la decisión pendiente? Si la respuesta exige abrir seis hojas de cálculo y convocar tres reuniones, el problema no es que falte otro marco. El problema es que el mapa todavía no está gobernando nada.