ISO 27001, control 8.25: qué pide sobre desarrollo seguro y qué evidencias revisa el auditor

Por Kike Gandia · Co-Fundador y CEO, OSCP · Última actualización: noviembre de 2026

La versión de 2022 de ISO 27001 agrupa en el anexo A varios controles sobre desarrollo de software, y el primero es el 8.25: ciclo de vida de desarrollo seguro. Si tu empresa desarrolla software y se está certificando, o si tus clientes están certificados y te auditan como proveedor, estos controles son los que marcan la conversación. Esta guía explica qué dice el 8.25, cómo se relaciona con los controles de alrededor y qué evidencias suelen pedirse.

Qué dice el control 8.25

El control 8.25 pide establecer y aplicar reglas para el desarrollo seguro de software y sistemas. Es un control de proceso: no exige una herramienta concreta, sino que la organización tenga definidas unas reglas, que las aplique y que pueda demostrarlo.

La guía de implantación está en ISO/IEC 27002:2022, que propone, entre otras cosas, separar entornos, aplicar seguridad en la metodología de desarrollo, usar guías de codificación segura, incluir requisitos de seguridad en la especificación y el diseño, establecer puntos de control de seguridad en los proyectos, hacer pruebas, proteger los repositorios y gestionar las versiones.

Los controles de desarrollo, en una tabla

Control	Nombre	Qué suele pedir el auditor
8.25	Ciclo de vida de desarrollo seguro	Una política o procedimiento de desarrollo seguro y evidencia de que se sigue
8.26	Requisitos de seguridad de las aplicaciones	Requisitos de seguridad identificados y aprobados en los proyectos
8.27	Arquitectura de sistemas seguros y principios de ingeniería	Principios de diseño seguro documentados y aplicados
8.28	Codificación segura	Guía de codificación segura, revisión de código y control de dependencias
8.29	Pruebas de seguridad en desarrollo y aceptación	Plan de pruebas de seguridad y sus resultados, incluido el pentest
8.30	Desarrollo externalizado	Cómo se dirige, supervisa y revisa el desarrollo que hace un tercero
8.31	Separación de los entornos de desarrollo, prueba y producción	Entornos separados y control de accesos a cada uno

En una auditoría, estos controles se miran juntos: el 8.25 es el paraguas y los demás son las piezas que demuestran que el proceso funciona.

Evidencias que suelen funcionar

Procedimiento de desarrollo seguro, corto y real: qué se hace en cada fase, quién lo hace y qué queda registrado.
Requisitos de seguridad en los proyectos, por ejemplo con referencia a un nivel de OWASP ASVS.
Revisiones de código visibles en el repositorio, con la lista de comprobación que se usa.
Resultados del pipeline: análisis de dependencias, de secretos y estático, con las excepciones aprobadas.
Informes de pentest y de re-test de las versiones importantes.
Separación de entornos y control de quién accede a producción.
Formación del equipo en desarrollo seguro.

El error habitual es redactar un procedimiento ambicioso que nadie sigue. Un auditor prefiere un proceso modesto con evidencias a uno perfecto sin ellas.

Si tu cliente está certificado: el control 8.30

El control 8.30 obliga a la organización certificada a dirigir, supervisar y revisar el desarrollo que externaliza. Si eres su proveedor, eso se traduce en que te pedirá cosas: cláusulas de seguridad en el contrato, derecho a auditarte, tus prácticas de desarrollo seguro, resultados de pruebas y, a menudo, un pentest antes de aceptar la entrega.

Tener tu propio proceso alineado con el 8.25 hace que esas peticiones se respondan con documentos que ya existen, en lugar de con un esfuerzo nuevo en cada proyecto.

Cómo encaja el pentest

El pentest es la evidencia más clara del control 8.29, y sirve también para demostrar que el 8.25 funciona: si el proceso es bueno, los hallazgos del pentest son pocos y se corrigen rápido. Un informe de pentest con su re-test, hecho por un tercero independiente, es de lo primero que pide un auditor o un cliente que te supervisa.

FAQ

¿Qué es el control 8.25 de ISO 27001?

Es el control del anexo A de ISO 27001:2022 que pide establecer y aplicar reglas para el desarrollo seguro de software y sistemas. En la versión de 2013 su equivalente era el control A.14.2.1, política de desarrollo seguro.

¿El control 8.25 obliga a hacer un pentest?

No lo exige con ese nombre, pero el control 8.29 pide pruebas de seguridad durante el desarrollo y en la aceptación, y el pentest es la forma más habitual y fácil de demostrar de cumplirlo en aplicaciones expuestas.

¿Aplica el 8.25 si no desarrollamos software?

Si la organización no desarrolla, el control se puede excluir justificándolo en la declaración de aplicabilidad. Pero si encarga desarrollos a terceros, el control 8.30 sí aplica, y obliga a supervisar a ese proveedor.

¿Qué documentos hacen falta?

Como mínimo, un procedimiento de desarrollo seguro y las evidencias de que se aplica: requisitos de seguridad en los proyectos, revisiones de código, resultados de las pruebas y separación de entornos. No hace falta un documento por control; sí que cada control tenga respuesta.

¿Dónde está el detalle de cómo implantarlo?

En ISO/IEC 27002:2022, la guía de controles que acompaña a ISO 27001. Para el desarrollo seguro, marcos como NIST SSDF, OWASP SAMM y OWASP ASVS ayudan a concretar qué hacer en cada fase.