Gestión de claves criptográficas para ISO 27001, NIS2 y DORA

A las 08:17 de un lunes por la mañana, el director de seguridad de la información (CISO) de una empresa SaaS europea recibe un mensaje del responsable de ingeniería: “Rotamos la clave de cifrado de la base de datos durante el fin de semana, pero una integración dejó de descifrar registros. Hicimos una reversión usando una clave antigua de la bóveda”.

Diez minutos después, el delegado de protección de datos (DPO) pregunta si los registros afectados incluyen datos personales de la UE. Finanzas pregunta si esto podría convertirse en un incidente operativo notificable para un cliente regulado. Adquisiciones pregunta si el proveedor de servicios en la nube o la empresa es quien posee la clave gestionada por el cliente. El director general plantea la única pregunta que importa en el consejo de administración: “¿Podemos demostrar que lo gestionamos correctamente?”.

Ese es el momento en que “usamos cifrado” deja de ser una frase tranquilizadora y se convierte en un problema de evidencias.

En 2026, la gestión de claves criptográficas se sitúa en la intersección de los controles de ISO/IEC 27001:2022, la higiene cibernética de NIS2, la gestión del riesgo relacionado con las TIC de DORA, las evidencias de seguridad del tratamiento del Article 32 de GDPR, la responsabilidad compartida en la nube y la planificación de criptoagilidad poscuántica. El problema real no es si existe cifrado. El problema real es si la organización puede demostrar, con registros, que las claves se generan de forma segura, se asignan a propietarios, se almacenan en entornos KMS o HSM aprobados, se rotan según calendario, se recuperan de forma segura, se revocan cuando están comprometidas y se mapean al riesgo de las operaciones de la organización.

Clarysec observa el mismo patrón de forma recurrente en trabajos de preparación. El cifrado se implanta sistema por sistema, pero la gobernanza de claves está fragmentada. Los certificados viven en hojas de cálculo. Los permisos de KMS en la nube se heredan de proyectos antiguos. Los desarrolladores saben qué secretos importan, pero el SGSI no. Los auditores reciben capturas de pantalla en lugar de evidencias del ciclo de vida. Los equipos de NIS2 y DORA hablan de resiliencia, los equipos de privacidad hablan de cifrado y seudonimización conforme a GDPR, y nadie es propietario de extremo a extremo del plano de control criptográfico.

Una respuesta madura no consiste en más criptografía de forma aislada. Consiste en una gestión de claves criptográficas gobernada, conectada con el tratamiento de riesgos, la arquitectura en la nube, la supervisión de proveedores, el control de acceso, el registro de eventos, la respuesta a incidentes y las evidencias regulatorias.

Por qué la gestión de claves es ahora una cuestión de gobernanza

NIS2 convierte las políticas de criptografía y cifrado en parte de las medidas mínimas de gestión de riesgos de ciberseguridad para entidades esenciales e importantes. El Article 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas, que incluyen análisis de riesgos, gestión de incidentes, continuidad, seguridad de la cadena de suministro, desarrollo seguro, higiene cibernética, control de acceso, gestión de activos y políticas de criptografía y cifrado. También exige que los órganos de dirección aprueben y supervisen las medidas de gestión de riesgos de ciberseguridad.

Para proveedores SaaS, proveedores de servicios en la nube, proveedores de servicios gestionados y proveedores de ciberseguridad, la aplicabilidad puede ser más amplia de lo que muchos equipos presuponen. NIS2 cubre sectores como infraestructura digital, proveedores de servicios de computación en la nube, proveedores de centros de datos, proveedores DNS, prestadores de servicios de confianza, proveedores de servicios gestionados, proveedores de servicios gestionados de seguridad, mercados en línea, motores de búsqueda y plataformas de redes sociales cuando se cumplen los umbrales de tamaño o criticidad.

DORA eleva el nivel de exigencia para las entidades financieras. Desde el 17 de enero de 2025, DORA exige un marco documentado de gestión del riesgo relacionado con las TIC, responsabilidad del consejo de administración, continuidad del negocio de las TIC y planes de respuesta y recuperación, pruebas de resiliencia operativa digital, gestión del riesgo de terceros de TIC y notificación de incidentes. Para las entidades financieras identificadas conforme a las normas nacionales de NIS2, DORA funciona como el acto jurídico sectorial específico de la Unión para las obligaciones equivalentes de NIS2. Una fintech no debe ejecutar una gobernanza criptográfica separada para NIS2, DORA e ISO. Necesita un único modelo de control jurídicamente defendible.

GDPR añade la dimensión de evidencias de privacidad. El Article 32 de GDPR es donde el cifrado suele evaluarse como salvaguarda de seguridad del tratamiento, pero “los datos están cifrados” no es una respuesta completa. Reguladores y auditores preguntan quién controla las claves, cómo se restringe el acceso, cómo se detecta un compromiso, cómo funciona la recuperación y si el diseño se ajusta al riesgo para las personas.

ISO/IEC 27001:2022 proporciona a las organizaciones el sistema de gestión para articular estas obligaciones. Las cláusulas 4.1 a 4.4 exigen contexto, requisitos de las partes interesadas, alcance del SGSI y procesos que interactúan. Las cláusulas 5.1 a 5.3 exigen liderazgo, política, recursos y responsabilidades asignadas. Las cláusulas 6.1.1 a 6.1.3 exigen evaluación de riesgos, tratamiento de riesgos, selección de controles, una Declaración de Aplicabilidad y aprobación por el propietario del riesgo. Las cláusulas 8.1 a 8.3 exigen operación controlada, reevaluación del riesgo cuando se produzcan cambios, implantación de planes de tratamiento y conservación de resultados documentados.

Para la gestión de claves criptográficas, el SGSI debe responder a cinco preguntas:

1. ¿Qué activos de información, flujos de datos y servicios requieren protección criptográfica?
2. ¿Qué claves, certificados, secretos y servicios criptográficos los protegen?
3. ¿Quién posee, administra, aprueba y supervisa esos activos criptográficos?
4. ¿Cómo se controlan la generación, el almacenamiento, el uso, la rotación, el depósito, la recuperación, la revocación y la destrucción?
5. ¿Qué evidencias demuestran que los controles funcionaron según lo diseñado?

La columna vertebral de controles ISO 27001 para la gestión de claves criptográficas

Clarysec trata la gestión de claves criptográficas como una cadena de controles, no como un único control. En Zenith Controls: The Cross-Compliance Guide Zenith Controls, el tema se mapea principalmente al control 8.24 de ISO/IEC 27002:2022, uso de la criptografía, con relaciones de soporte importantes con 5.17, información de autenticación, y 5.23, seguridad de la información para el uso de servicios en la nube.

Esa relación importa. Un fallo de gestión de claves rara vez es simplemente “mal cifrado”. A menudo es un problema de autenticación, un problema de gobernanza en la nube, un problema de proveedores, una deficiencia de registro o un fallo de gestión de cambios.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint lo operacionaliza en la fase de gestión de riesgos, Paso 14, políticas de tratamiento de riesgos y referencias cruzadas regulatorias. Su ejemplo de política de criptografía indica que la organización debe definir dónde se necesita la criptografía, aprobar algoritmos y protocolos, definir la gestión de claves, cubrir casos de uso como el cifrado completo de disco y las comunicaciones seguras, y conectar la política con el Article 32 de GDPR.

“Las claves de cifrado deben almacenarse de forma segura (por ejemplo, en una bóveda de claves/HSM) y el acceso debe limitarse al personal autorizado.”
Atribución: Zenith Blueprint, fase de gestión de riesgos, Paso 14, políticas de tratamiento de riesgos y referencias cruzadas regulatorias Zenith Blueprint

En la fase Controles en acción, Paso 20, Zenith Blueprint profundiza más. La criptografía no consiste en “activar el cifrado”. Consiste en incorporar la criptografía al diseño, la política y la gestión del ciclo de vida. Esto incluye datos en reposo, datos en tránsito, autenticación de identidades y transacciones, algoritmos aprobados, bóvedas de claves, HSM, rotación programada, revocación y validación mediante pruebas de penetración y revisión de código.

Qué esperan los auditores cuando solicitan evidencias de claves

La mayoría de los hallazgos de auditoría empiezan con una solicitud sencilla: “Muéstreme su política de cifrado y sus registros de gestión de claves”.

Las respuestas débiles incluyen:

• “El proveedor de servicios en la nube lo cifra todo por defecto.”
• “Usamos TLS.”
• “Los secretos están en la bóveda.”
• “El equipo de ingeniería gestiona la rotación.”
• “La clave la gestiona la aplicación.”

Estas afirmaciones pueden ser técnicamente ciertas, pero no constituyen evidencias completas. Un auditor ISO conectará la gestión de claves con la evaluación de riesgos, la Declaración de Aplicabilidad, los requisitos de la política, el control operacional y la documentación conservada. Un evaluador de NIST CSF preguntará si los activos criptográficos están identificados, protegidos, supervisados y recuperados. Un auditor de DORA buscará gobernanza del riesgo relacionado con las TIC aprobada por el consejo de administración, dependencias de terceros, gestión de incidentes y pruebas de resiliencia. Un revisor de GDPR preguntará si el cifrado y la separación de claves reducen el riesgo para las personas y si el responsable del tratamiento puede demostrar responsabilidad proactiva.

La política empresarial Cryptographic Controls Policy de Clarysec Cryptographic Controls Policy aborda directamente la deficiencia de evidencias:

“Debe mantenerse un Registro de Gestión de Claves centralizado para registrar todas las claves criptográficas, su estado en el ciclo de vida, los custodios asignados y los contextos de uso.”
Atribución: política empresarial, Cryptographic Controls Policy, requisitos de gobernanza, cláusula 5.2 Cryptographic Controls Policy

Esa frase cambia la conversación de auditoría. En lugar de perseguir conocimiento tribal, la organización puede mostrar un registro que vincula claves con activos, propietarios, clasificaciones de datos, sistemas, cuentas en la nube, fechas de rotación, contextos de uso y evidencias.

Para pymes, Cryptographic Controls Policy-sme de Clarysec Cryptographic Controls Policy-sme - SME escala la misma expectativa:

“El proveedor de soporte de TI debe mantener un inventario actualizado de las herramientas criptográficas y los certificados en uso.”
Atribución: política para pymes, Cryptographic Controls Policy-sme, requisitos de gobernanza, cláusula 5.1.2 Cryptographic Controls Policy-sme - SME

Una entidad financiera regulada puede necesitar ceremonias HSM, conocimiento dividido, doble control, nombramientos formales de custodios y revisiones de acceso trimestrales. Un pequeño proveedor SaaS puede empezar con un inventario mantenido, algoritmos aprobados, titularidad documentada de KMS y evidencias de rotación. Ambos necesitan una gobernanza proporcionada al riesgo.

El ciclo de vida de claves que debe controlar su SGSI

Un programa práctico de gestión de claves sigue el ciclo de vida. Cada etapa necesita un propietario, un método aprobado, un control técnico, un registro de cambio y evidencias de auditoría.

La política empresarial Cryptographic Controls Policy refuerza la generación segura:

“Generación de claves: realizada mediante módulos seguros de hardware o software (por ejemplo, HSM, sistemas validados FIPS 140-2).”
Atribución: política empresarial, Cryptographic Controls Policy, requisitos de implantación de la política, cláusula 6.3.1 Cryptographic Controls Policy

También especifica la rotación:

“Rotación de claves: obligatoria a intervalos definidos o inmediatamente ante compromiso o cambio de función.”
Atribución: política empresarial, Cryptographic Controls Policy, requisitos de implantación de la política, cláusula 6.3.4 Cryptographic Controls Policy

Para pymes, el mismo principio aparece en un lenguaje operativo más sencillo:

“La rotación de claves debe realizarse conforme a los calendarios de caducidad o ante sospecha de compromiso.”
Atribución: política para pymes, Cryptographic Controls Policy-sme, requisitos de implantación de la política, cláusula 6.3.4 Cryptographic Controls Policy-sme - SME

Estas cláusulas son relevantes para NIS2 y DORA porque las claves obsoletas o mal gobernadas no son solo debilidades de confidencialidad. Pueden convertirse en bloqueos de respuesta a incidentes, problemas de dependencia de proveedores, fallos de recuperación ante desastres y problemas de notificación a clientes.

KMS en la nube, HSM y BYOK: la trampa de la responsabilidad compartida

El cifrado en la nube es una de las fuentes más habituales de falsa seguridad. Un proveedor de servicios en la nube puede cifrar el almacenamiento por defecto, pero eso no significa automáticamente que su organización haya gobernado la clave.

Zenith Blueprint, en la fase Controles en acción, Paso 23, explica el control 5.23 de ISO/IEC 27002:2022 centrándose en la gobernanza en la nube, la visibilidad y la responsabilidad compartida. Subraya que el proveedor puede proteger la infraestructura, pero el cliente sigue siendo responsable de sus datos, configuraciones, políticas de acceso y preparación de respuesta a incidentes.

“Los proveedores de servicios en la nube protegen la infraestructura, pero usted sigue siendo responsable de sus datos, sus configuraciones, sus políticas de acceso y su preparación de respuesta a incidentes.”
Atribución: Zenith Blueprint, fase Controles en acción, Paso 23, controles organizativos 5.19-5.37 Zenith Blueprint

Aquí es donde la responsabilidad sobre claves en la nube se convierte en un riesgo de nivel consejo de administración. Una empresa SaaS puede usar cifrado gestionado por el proveedor para registros de bajo riesgo, claves gestionadas por el cliente para bases de datos de clientes, BYOK para clientes regulados y claves raíz respaldadas por HSM para firma o tokenización. Cada elección tiene implicaciones de cumplimiento.

La política empresarial Cloud Usage Policy de Clarysec Cloud Usage Policy proporciona una directriz de control clara:

“Las claves gestionadas por el cliente (CMK) o Bring Your Own Key (BYOK) deberán usarse cuando el proveedor de servicios en la nube lo soporte.”
Atribución: política empresarial, Cloud Usage Policy, requisitos de implantación de la política, cláusula 6.4.2 Cloud Usage Policy

Esto no significa que todo servicio en la nube deba usar BYOK. Significa que la organización debe decidir deliberadamente, en función del riesgo, los compromisos con clientes, los requisitos contractuales y la capacidad de recuperación.

El Article 28 y el Article 30 de DORA hacen que esto sea especialmente relevante para las entidades financieras. Exigen gestión del riesgo de terceros de TIC, registros de acuerdos contractuales de TIC, diligencia debida, derechos de auditoría e inspección, asistencia en incidentes, protección y acceso a datos, y disposiciones de recuperación y devolución. Si un proveedor de servicios en la nube o un proveedor SaaS gestiona claves de cifrado para una función crítica o importante, esa relación debe ser visible en el registro de terceros de TIC y en los controles contractuales.

NIS2 también exige seguridad de la cadena de suministro, incluidas vulnerabilidades específicas de proveedores, prácticas de ciberseguridad y procedimientos de desarrollo seguro. Si un proveedor crítico conserva sus claves, opera su KMS, proporciona su HSM, gestiona el ciclo de vida de sus certificados o aloja copias de seguridad cifradas, el proveedor forma parte de su entorno de control criptográfico.

Aprobación de algoritmos y criptoagilidad en 2026

Una política de gestión de claves de 2026 no debe limitarse a enumerar “AES-256” y “TLS 1.2 o posterior”. Debe establecer un proceso de aprobación y revisión que soporte la criptoagilidad. La criptoagilidad significa que la organización puede identificar dónde se usan algoritmos, protocolos, certificados y longitudes de clave, evaluar la exposición a debilidades o retirada, y migrar sin pánico.

La política para pymes de Clarysec establece:

“Solo podrán usarse algoritmos y protocolos de mejores prácticas del sector aprobados por el proveedor de soporte de TI (por ejemplo, AES-256, RSA 2048, TLS 1.2 o posterior).”
Atribución: política para pymes, Cryptographic Controls Policy-sme, requisitos de implantación de la política, cláusula 6.2.1 Cryptographic Controls Policy-sme - SME

También exige documentación:

“Todos los métodos de cifrado (por ejemplo, AES-256, TLS 1.2+) y los procesos de gestión de claves deben documentarse.”
Atribución: política para pymes, Cryptographic Controls Policy-sme, requisitos de gobernanza, cláusula 5.3.1 Cryptographic Controls Policy-sme - SME

La versión preparada para auditoría es un estándar criptográfico aprobado con:

• Algoritmos y protocolos permitidos para datos en reposo, datos en tránsito, firmas, hashing de contraseñas, tokenización y copias de seguridad.
• Algoritmos, protocolos y bibliotecas no permitidos.
• Longitudes mínimas de clave y períodos de validez de certificados.
• Plataformas KMS, HSM, autoridad de certificación y herramientas de gestión de secretos aprobadas.
• Requisitos de generación segura de números aleatorios.
• Guía para desarrolladores sobre bibliotecas criptográficas.
• Proceso de excepción para sistemas heredados.
• Desencadenantes de revisión por vulnerabilidades, cambios regulatorios, cambios de proveedores y planificación de transición poscuántica.

La planificación poscuántica no exige que todas las organizaciones sustituyan toda la criptografía de inmediato. Sí exige inventario. Sin un inventario criptográfico, no puede saber qué sistemas usan cifrado de clave pública de larga duración, qué certificados protegen servicios críticos, dónde residen las claves de firma o qué proveedores deben soportar la migración. El Registro de Gestión de Claves no es burocracia. Es la base de la criptoagilidad.

Sprint de evidencias de gestión de claves en 90 minutos

Clarysec suele usar un breve sprint de evidencias con equipos de dirección, seguridad, nube y cumplimiento. El objetivo es convertir rápidamente conocimiento disperso sobre claves en evidencias de auditoría.

Paso 1: Seleccionar un servicio crítico

Elija un sistema relevante para NIS2, DORA o GDPR. Algunos ejemplos son identidad de clientes, procesamiento de pagos, monitorización de transacciones, base de datos de clientes de producción, plataforma de copias de seguridad cifradas o API orientada al cliente.

Paso 2: Abrir el Registro de Gestión de Claves

Use el requisito de Cryptographic Controls Policy sobre un registro centralizado como estructura. Si aún no tiene uno, cree un registro sencillo con estos campos:

Paso 3: Trazar el acceso y el doble control

Para operaciones criptográficas de alto impacto, aplique doble control y mínimo privilegio. La política empresarial Cryptographic Controls Policy establece:

“Los principios de doble control y mínimo privilegio deben aplicarse a operaciones criptográficas sensibles (por ejemplo, importaciones de claves raíz, administración de HSM).”
Atribución: política empresarial, Cryptographic Controls Policy, requisitos de implantación de la política, cláusula 6.6.2 Cryptographic Controls Policy

Pregunte:

• ¿Quién puede deshabilitar o eliminar la clave?
• ¿Quién puede cambiar la política de la clave?
• ¿Quién puede descifrar datos directamente?
• ¿Los roles de emergencia están supervisados y limitados en el tiempo?
• ¿Se aplica MFA para operaciones privilegiadas sobre claves?
• ¿Las acciones privilegiadas se registran y revisan?

Paso 4: Extraer cinco registros de evidencias

Recopile cinco registros que demuestren que el control funciona:

1. Registro de creación o importación de clave.
2. Política de acceso actual de KMS o HSM.
3. Último ticket de cambio de rotación de clave.
4. Consulta SIEM que muestre uso de claves o acciones administrativas.
5. Evidencia de prueba de recuperación o restauración.

Paso 5: Mapear a riesgo y regulación

Añada una breve declaración de riesgo: “El uso no autorizado o la pérdida de esta clave podría exponer datos personales de la UE, interrumpir el servicio al cliente y perjudicar la recuperación de sistemas críticos”. A continuación, mapee la evidencia con las obligaciones pertinentes.

En 90 minutos, el equipo normalmente puede identificar si la gobernanza de claves es real o solo asumida.

Notificación de incidentes: cuando el compromiso de claves pone en marcha el reloj

Un presunto compromiso de claves no es automáticamente una brecha notificable, pero puede activar el reloj regulatorio.

Conforme a NIS2, las entidades esenciales e importantes deben notificar sin dilación indebida los incidentes significativos que afecten a la prestación del servicio. El modelo por fases incluye una alerta temprana en las 24 horas siguientes a la toma de conocimiento, una notificación de incidente en 72 horas, actualizaciones de estado cuando se soliciten y un informe final a más tardar un mes después de la notificación del incidente.

Conforme a DORA, las entidades financieras deben detectar, gestionar y notificar incidentes relacionados con las TIC, registrar incidentes y ciberamenazas significativas, clasificar los incidentes por severidad y criticidad del servicio afectado, comunicarse con las partes interesadas, informar de incidentes graves a la alta dirección y a las autoridades competentes, realizar análisis de causa raíz y remediar. La externalización de la notificación puede ser posible, pero la responsabilidad permanece en la entidad financiera.

Conforme a GDPR, la cuestión pasa a ser si se produjo una brecha de datos personales, es decir, la destrucción, pérdida, alteración, divulgación no autorizada o acceso a datos personales, de forma accidental o ilícita. Un cifrado sólido con claves no comprometidas puede cambiar materialmente el análisis del riesgo de brecha. Una gestión de claves débil puede socavar ese argumento.

Los procedimientos de respuesta ante compromiso de claves deben definir:

• Cómo se detecta una presunta exposición de claves.
• Quién declara un incidente criptográfico.
• Cómo se identifican los datos, servicios, clientes y jurisdicciones afectados.
• Cómo se revocan o rotan las claves.
• Cómo se restauran los sistemas dependientes.
• Cómo se preserva la integridad de las evidencias.
• Cómo se toman decisiones legales, regulatorias y de notificación a clientes.

El Registro de Gestión de Claves se vuelve esencial durante este proceso. Sin él, los equipos de respuesta pierden tiempo identificando qué protegía una clave. Con él, pueden delimitar el impacto rápidamente.

La perspectiva de auditoría: un conjunto de controles, muchos consumidores de evidencias

Distintos auditores abordan la gestión de claves criptográficas desde perspectivas diferentes, pero convergen en las mismas evidencias.

Un paquete sólido de auditoría para la gestión de claves criptográficas suele contener:

• Cryptographic Controls Policy aprobada.
• Cloud Usage Policy aprobada cuando el cifrado en la nube sea relevante.
• Estándar criptográfico y lista de algoritmos.
• Registro de Gestión de Claves.
• Inventario de certificados y secretos.
• Arquitectura de KMS, HSM y bóveda.
• Evidencias de revisiones de IAM y acceso privilegiado.
• Registros de rotación y revocación.
• Evidencias de pruebas de copia de seguridad, depósito y recuperación.
• Reglas de registro y supervisión para la actividad de claves.
• Mapeo de proveedores y responsabilidad compartida en la nube.
• Procedimiento de respuesta ante presunto compromiso de claves.
• Excepciones y aceptaciones de riesgo.
• Registros de revisión por la dirección y remediación de auditoría.

Este paquete convierte una afirmación de control en prueba.

Hallazgos habituales en auditorías de gestión de claves

Los hallazgos más habituales son evitables:

1. No existe un inventario único de claves, certificados y herramientas criptográficas.
2. El cifrado por defecto del proveedor de servicios en la nube se trata como gobernanza completa de claves.
3. No hay propietario ni custodio asignado a las claves de producción.
4. Existe rotación para certificados, pero no para claves de aplicación o CMK de bases de datos.
5. Secretos y claves se mezclan en la misma bóveda sin clasificación.
6. Los desarrolladores pueden crear claves fuera de patrones aprobados.
7. No hay evidencia de que los administradores de KMS sean revisados.
8. Existen procedimientos de recuperación, pero nunca se han probado.
9. El compromiso de claves no está incluido en los procedimientos de respuesta a incidentes.
10. Los algoritmos heredados permanecen en servicios internos porque nadie es propietario de la remediación.
11. Los compromisos BYOK se asumen en contratos con clientes, pero no se reflejan en las operaciones.
12. El cifrado gestionado por proveedores no se incluye en las revisiones de riesgo de proveedores.

Cada hallazgo vuelve a la gobernanza. Por eso la criptografía no puede tratarse como un proyecto puramente de ingeniería. Debe conectarse con el alcance del SGSI, el tratamiento de riesgos, la política, los proveedores, la nube, el acceso, el registro de eventos, los incidentes y la continuidad.

Prepare la gobernanza de claves para auditorías antes del próximo incidente

Si su organización se está preparando para NIS2, DORA, evidencias del Article 32 de GDPR, certificación ISO/IEC 27001:2022 o criptoagilidad poscuántica, empiece por una pregunta: ¿puede generar hoy un Registro de Gestión de Claves completo?

Si no, Clarysec puede ayudarle a construir el sistema de control alrededor de él.

Use Zenith Blueprint Zenith Blueprint para estructurar el trabajo mediante la fase de gestión de riesgos, Paso 14, y la fase Controles en acción, Paso 20. Use Zenith Controls Zenith Controls para mapear los controles 8.24, 5.17 y 5.23 de ISO/IEC 27002:2022 con NIS2, DORA, GDPR, NIST y expectativas de auditoría. Use Cryptographic Controls Policy de Clarysec Cryptographic Controls Policy, Cryptographic Controls Policy-sme Cryptographic Controls Policy-sme - SME y Cloud Usage Policy Cloud Usage Policy para convertir requisitos en reglas operativas.

El siguiente paso práctico es sencillo: elija un servicio crítico, inventaríe sus claves, demuestre la propiedad, verifique el acceso, extraiga evidencias de rotación y pruebe la recuperación. Si eso requiere más de un día, su gobernanza criptográfica necesita atención antes de que el regulador, el auditor o el equipo de respuesta a incidentes formule la misma pregunta bajo presión.