ISO 27001, anexo A, 8.24: Guía práctica sobre criptografía y gestión de claves para proveedores de servicios de TI

Para la mayoría de los proveedores de TI y de servicios de « software », la certificación ISO 27001 ha dejado de ser, sin que nadie se haya dado cuenta, algo «que está bien tener». Se ha convertido en una condición imprescindible para hacer negocios. Los cuestionarios de seguridad de los clientes, las solicitudes de propuestas y las evaluaciones de riesgo de los proveedores exigen cada vez más que se disponga de una certificación vigente antes de que un acuerdo pueda seguir adelante, lo que significa que un certificado caducado ya no es solo un problema de cumplimiento normativo. Es un riesgo para los ingresos.

La criptografía ocupa un lugar central en ese cambio. La revisión de 2022 de la norma agrupó la criptografía y la gestión de claves en un único control claramente definido: el anexo A, apartado 8.24, «Uso de la criptografía». Esta guía desglosa qué ha cambiado en la revisión de 2022, qué exige realmente el control 8.24 y cómo demostrarlo ante un auditor antes de tu próxima visita de supervisión.

¿Qué ha cambiado en la norma ISO/IEC 27001:2022?

La revisión de 2022 reestructuró el Anexo A en 93 controles organizados en cuatro temas. En lo que respecta a la criptografía, el cambio más importante es la consolidación: los dos controles independientes de la edición de 2013 (A.10.1.1, «Política sobre el uso de controles criptográficos», y A.10.1.2, «Gestión de claves») se fusionaron en un único control: 8.24, «Uso de la criptografía».

Esa consolidación es importante para la forma en que los equipos documentan y acreditan su programa criptográfico. En lugar de tratar la gestión de políticas y claves como dos requisitos vagamente relacionados entre sí, la sección 8.24 exige una visión coherente: un enfoque definido de la criptografía y un ciclo de vida gestionado para las claves que la sustentan, ambos vinculados entre sí y respaldados por pruebas.

Qué exige realmente la norma 8.24

La norma 8.24 se sustenta en dos pilares.

La primera es una política de criptografía documentada y basada en el riesgo que define los algoritmos autorizados y los niveles mínimos de seguridad de las claves. La segunda es una gestión del ciclo de vida de las claves que abarca toda la vida útil de una clave: generación, distribución, revocación, gestión de claves comprometidas, recuperación de claves perdidas, almacenamiento, rotación, copia de seguridad y destrucción.

El punto crítico para las empresas de TI y de « software » es cómo comprueban esto los auditores. Estos verifican el apartado 8.24 mediante pruebas operativas, no solo a través de declaraciones de políticas. En la práctica, esto significa el inventario de certificados y claves, los registros de rotación que demuestren que se ha cumplido efectivamente el intervalo establecido en la política, los resultados de la configuración de « TLS » y del cifrado, los registros de acceso al HSM o al KMS, y los registros de destrucción con firma de verificación. Una política bien redactada de la que nadie pueda demostrar que se está cumpliendo no satisfará a un evaluador. Y dado que la cláusula 8.24 se aplica al producto, su alcance incluye habitualmente la criptografía integrada en el propio producto, no solo el entorno informático interno.

Por qué es importante el cumplimiento de la norma ISO 27001 en materia de criptografía para los proveedores de TI

La certificación ISO 27001 es, técnicamente, voluntaria. En la práctica, para los proveedores de TI y de « software », se ha convertido en un requisito comercial de facto. Los cuestionarios de seguridad, las solicitudes de propuestas (RFP) y las evaluaciones de riesgo de los proveedores exigen cada vez más contar con una certificación vigente como condición para hacer negocios, por lo que una deficiencia en sus controles criptográficos puede paralizar el proceso de adquisición y costarle contratos; esto llega al departamento de compras por una de estas dos vías: o bien sale a la luz directamente en una respuesta a un cuestionario de seguridad que no puede justificar, o bien se convierte en un incumplimiento que pone en riesgo el propio certificado.

También hay que tener en cuenta la dimensión temporal. Dado que la norma ISO 27001 es una norma de sistemas de gestión, el apartado 8.24 no se comprueba una sola vez y luego se olvida.  Las auditorías de vigilancia examinan el SGSI por muestreo, en lugar de comprobar todos y cada uno de los controles, por lo que el punto 8.24 puede aparecer o no en un año determinado. La recertificación es diferente: confirma que el sistema cumple todos los requisitos de la norma, no solo las áreas sometidas a muestreo durante la vigilancia. En la práctica, no se puede predecir en qué año se examinará la criptografía. Esa periodicidad recompensa a las organizaciones que mantienen un control continuo y con pruebas disponibles sobre la criptografía, en lugar de tener que apresurarse a reconstruirlo antes de cada auditoría.

Vale la pena saber cómo se pierde realmente un certificado: una no conformidad grave no lo invalida de inmediato. Los organismos de certificación establecen un plazo determinado para subsanar la no conformidad, y la suspensión o retirada solo se produce si no se subsana. El riesgo comercial no radica tanto en «no hemos superado una auditoría» como en «hemos pasado un trimestre con una no conformidad grave pendiente que hemos tenido que comunicar».

Cómo se corresponde la sección 8.24 con los controles criptográficos reales

El control 8.24 no existe de forma aislada. Está vinculado a un conjunto de áreas de control prácticas que los evaluadores esperan que funcionen de forma coordinada en todo el ámbito de la certificación.

Una política documentada sobre criptografía y gestión de claves (Anexo A, 8.24)

En esencia, la norma 8.24 exige una política específica para cada tema que defina los algoritmos autorizados, las longitudes mínimas de las claves y las normas relativas al ciclo de vida. Dicha política debería estar directamente vinculada a la evaluación de riesgos del SGSI, de modo que cada decisión criptográfica se remonte a un riesgo documentado y no a una mera preferencia.

El ciclo de vida de las claves criptográficas (Anexo A, apartado 8.24)

El ciclo de vida es el punto en el que la criptografía sólida suele fallar con mayor frecuencia. Los auditores esperan que la generación, distribución, rotación y destrucción de claves y certificados —incluidos los integrados en los dispositivos « software » que se suministran— se realicen de forma centralizada, todo ello respaldado por un registro de auditoría completo. La revocación, la gestión de claves comprometidas, la recuperación de claves perdidas, el almacenamiento seguro y las copias de seguridad completan el panorama.

Confidencialidad e integridad de los datos (Anexo A, apartados 5.14, 8.20 y 8.21; datos personales, según el apartado 5.34)

La criptografía existe para proteger los datos. Según el apartado 8.24, la criptografía es el mecanismo; los controles que establecen la obligación se encuentran en otros apartados. El anexo A, apartados 5.34 (transferencia de información) y 8.20-8.21 (seguridad de las redes y de los servicios de red), regulan el cifrado en tránsito. Los certificados emitidos por la PKI protegen los datos de los clientes tanto en reposo como en tránsito dentro del ámbito certificado. En el caso de los proveedores de « software », ese ámbito suele extenderse a entornos SaaS multitenant, en los que muchos clientes comparten la misma infraestructura.

Criptografía de productos (Anexo A, apartados 8.25, 8.26 y 8.28)

Si la tecnología criptográfica forma parte de lo que vendes, el ciclo de vida de desarrollo seguro (8.25), los requisitos de seguridad de las aplicaciones (8.26) y la programación segura (8.28) son los aspectos en los que los auditores comprueban si las decisiones sobre algoritmos y longitud de claves establecidas en tu política 8.24 se reflejan realmente en el código fuente. Los controles de proveedores abarcan las bibliotecas heredadas; estos, por su parte, abarcan tu propio código.

Autenticación segura (Anexo A, apartado 8.5)

El apartado 8.5 del anexo A introduce la autenticación en el contexto de la criptografía. La autenticación basada en certificados reduce la dependencia de secretos compartidos y contraseñas estáticas, tanto en el acceso de los clientes como en el administrativo, sustituyendo las credenciales, que pueden filtrarse fácilmente, por identidades que son mucho más difíciles de utilizar indebidamente.

Supplier and inherited cryptography (Annex A 5.21, 8.8)
Modern software inherits cryptography from libraries and third parties. Annex A 8.24 requires a key management system to handle key revocation, compromised keys. Every one of those duties is owed per key, and a per-key duty presupposes knowing which keys exist. For Annex A 8.8, an accurate asset inventory is a prerequisite for effective vulnerability management. Annex A 5.21 extends the question into the ICT supply chain, where the components are someone else’s code. Read together, the inventory is not a stated requirement; it is the only practical way to evidence four that are.

Statement of Applicability traceability (Clause 6.1.3)
Finally, Clause 6.1.3 ties it all back to governance. Centralized reporting that maps cryptographic controls to documented risk treatment decisions gives auditors a clear, traceable line from a control to the risk it addresses.

Prepararse para la auditoría: qué es lo que examinan los auditores

Cuando un evaluador llega al punto 8.24, busca pruebas, no intenciones. Las siguientes áreas son las que analiza sistemáticamente:

• Una política de criptografía documentada que abarque tanto los sistemas internos como los productos comercializados, en la que se definan los algoritmos autorizados, las longitudes mínimas de las claves y las condiciones en las que el cifrado es obligatorio.
• Pruebas del ciclo de vida de las llaves: registros, no procedimientos: registros de rotación que demuestren que se ha cumplido el intervalo establecido en la política, registros de destrucción con firma de verificación, registros de actividad por llave y fechas de activación y desactivación.
• Declaración de trazabilidad de la aplicabilidad que justifica la inclusión del punto 8.24 y la vincula a la evaluación de riesgos subyacente.
• Cumplimiento normativo y jurisdiccional, incluidos los controles de exportación y las consideraciones relativas a la residencia de los datos.
• Un inventario actualizado de certificados y claves con los nombres de los titulares y las fechas de caducidad, incluidas las claves integradas en las versiones de software .
• Pruebas de auditoría interna de los controles 8.24, cuyos resultados son revisados por la dirección dentro del ciclo del SGSI.
• Política de conformidad de la configuración. Los evaluadores comparan los algoritmos y las longitudes de clave que aprueba la política con lo que realmente se ha implementado. La discrepancia entre la política y la realidad constituye un incumplimiento, incluso cuando tanto la política como la configuración sean defendibles por separado.

El denominador común es la propiedad y la trazabilidad. Cada afirmación que se haga sobre la criptografía debe estar respaldada por un elemento que un auditor pueda examinar.

Cómo Keyfactor ayudarte Keyfactor

La reunión 8.24 se centra en la visibilidad, las normas establecidas y una gestión disciplinada de las claves a gran escala. La plataforma de Keyfactorse ajusta perfectamente a las áreas de control mencionadas anteriormente.

• AgileSec elabora el inventario de componentes criptográficos que respalda la garantía de los proveedores y genera pruebas de la Declaración de aplicabilidad para componentes integrados o de terceros.
• EJBCA proporciona la infraestructura de clave pública (PKI) que garantiza la confidencialidad y la integridad de los datos protegidos por certificados, junto con una gestión centralizada del ciclo de vida de las claves, incluidas las claves integradas en los dispositivos « software » que se suministran.
• Keyfactor Command aplica la política, ofrece visibilidad sobre el ciclo de vida de las claves, gestiona el inventario de certificados y claves, y elabora informes de trazabilidad de la Declaración de aplicabilidad.

En conjunto, estas capacidades crean un único sistema de registro para la criptografía, que genera exactamente la documentación que solicita un auditor de la norma ISO 27001, en lugar de obligar a los equipos a recopilarla manualmente.

Conclusión y próximos pasos

El mensaje que se desprende de la versión 8.24 es coherente: el control prima la titularidad, la trazabilidad y las pruebas frente a las declaraciones de política. La certificación depende menos de que un documento contenga las palabras adecuadas y más de la capacidad de demostrar, cuando se solicite, cómo se rige la criptografía y cómo se gestionan las claves.

El siguiente paso práctico es muy sencillo. Evalúa tu política de criptografía actual y tu inventario de claves a la luz del apartado 8.24 antes de tu próxima auditoría, y centraliza la documentación en lugar de tenerla dispersa en distintas hojas de cálculo.

¿Estás listo para ver cómo se ajusta la criptografía automatizada y la gestión del ciclo de vida de las claves a lo establecido en el anexo A, apartado 8.24? Solicitar una demo.

¿Tienes dudas sobre la criptografía en la norma ISO 27001? Tenemos las respuestas.

What is ISO/IEC 27001 Annex A 8.24?
Annex A 8.24, Use of Cryptography, is the ISO 27001:2022 control governing how an organization uses cryptography. It requires a documented, risk-based cryptography policy and a managed key lifecycle, verified through operational evidence rather than policy statements alone. Annex A itself states the control in a single sentence; the detailed expectations sit in ISO/IEC 27002:2022, which auditors use as the yardstick.

What changed for cryptography in the 2022 revision?
The 2022 revision restructured Annex A into 93 controls across four themes. It consolidated the 2013 edition’s separate cryptography and key management controls into a single control, 8.24.

Does 8.24 cover cryptography inside the products we ship?
Yes. For software and IT service companies, the scope of 8.24 routinely includes cryptography embedded in the product itself, not only the internal IT environment.

What does a compliant cryptography policy need to include?
It should be a topic-specific policy defining approved algorithms, minimum key lengths, and the conditions under which encryption is mandatory. It must be tied to the ISMS risk assessment and cover both internal systems and shipped products.

What key lifecycle evidence do auditors expect?
Auditors expect demonstrated procedures for key generation, secure storage, rotation, and destruction, not just a written policy. A current certificate and key inventory with named owners and expiry dates supports this.

How often is 8.24 tested?
Because ISO 27001 is a management-system standard, 8.24 is tested at annual surveillance audits and in full at the three-year recertification.

Why does ISO 27001 certification matter commercially?
Certification has become a de facto commercial prerequisite for IT and software vendors. Security questionnaires, RFPs, and supplier risk assessments increasingly require current certification, so a lapsed certificate can directly threaten revenue.

How does 8.24 relate to the Statement of Applicability?
The Statement of Applicability must justify including 8.24 and link it to the underlying risk assessment. Centralized reporting that maps cryptographic controls to documented risk treatment decisions supports auditor review under Clause 6.1.3.