Esta lista de verificación de seguridad del SDLC mapea los controles de desarrollo de software cláusula por cláusula al Anexo A de ISO/IEC 27001:2022, específicamente el grupo A.8.25–A.8.34 y los controles relacionados, para que los responsables de cumplimiento, los gestores de TI y los líderes de seguridad puedan especificar los controles aplicables en su Declaración de Aplicabilidad, recopilar evidencias auditables y presupuestar el trabajo de implementación con confianza. Continúe leyendo para conocer las tareas a nivel de cláusula, ejemplos de evidencias y enlaces de planificación de Ismscalculator.
Lo que obtendrá de esta lista de verificación:
- Mapeo cláusula a cláusula de los controles del SDLC al Anexo A de ISO 27001 (A.8.25–A.8.34, A.5.23, A.8.8, A.8.9)
- Tareas concretas de la lista de verificación con requisitos mínimos de evidencia y roles responsables
- Señales de alerta para auditorías y verificaciones internas rápidas antes de la Fase 2
- Rangos de esfuerzo y un desglose de Gantt de muestra para la elaboración de presupuestos
- Enlaces a las herramientas de Ismscalculator para estimaciones de costes y plazos personalizadas
Tabla de contenidos
- ¿Qué cubre la lista de verificación de seguridad del SDLC en el marco de ISO 27001?
- ¿Cómo se recopilan y presentan las evidencias para cada elemento de la lista?
- ¿Quién es responsable de qué? Gobernanza de los controles del SDLC en el SGSI
- ¿Cuánto tiempo lleva implementar los controles del SDLC y cuánto cuesta?
- ¿Dónde puede obtener una plantilla de lista de verificación y adaptarla a su organización?
- Conclusiones clave
- Lo que la mayoría de los equipos hace mal con los controles del SDLC
- Ismscalculator convierte esta lista de verificación en un presupuesto y un plan de proyecto
- Fuentes útiles y lecturas adicionales
¿Qué cubre la lista de verificación de seguridad del SDLC en el marco de ISO 27001?
ISO/IEC 27001:2022 reorganizó el Anexo A e incluyó de forma explícita la seguridad de las aplicaciones. La revisión de 2022 consolidó los controles e introdujo nuevos que cubren el ciclo de vida completo del desarrollo de software, con la transición a la línea base de 2022 completada el 31 de octubre de 2025. Diez controles del tema tecnológico (A.8.25 a A.8.34), más A.5.23, A.8.9 y A.8.16, forman un grupo de 13 controles de seguridad de aplicaciones (AppSec) que los auditores suelen revisar durante las auditorías de Fase 2.
La tabla siguiente mapea cada cláusula principal con las tareas de la lista de verificación, la evidencia mínima y el responsable sugerido.
| Cláusula ISO | Tarea de la lista de verificación | Evidencia mínima | Responsable |
|---|---|---|---|
| Ciclo de vida de desarrollo seguro | Documentar y aplicar normas para la planificación, el diseño, la codificación, las pruebas, el despliegue y el mantenimiento | Política de desarrollo seguro firmada por el responsable del SGSI; documento de procedimiento con historial de versiones | Gestor del SGSI / Product Owner |
| Requisitos de seguridad de las aplicaciones | Definir y documentar los requisitos de seguridad antes de que comience el desarrollo | Especificación de requisitos con criterios de aceptación de seguridad; modelo de amenazas o entrada en el registro de riesgos | Product Owner / Ingeniero de seguridad |
| Arquitectura e ingeniería de sistemas seguros | Aplicar principios de diseño seguro (mínimo privilegio, defensa en profundidad, valores predeterminados a prueba de fallos) | Registro de revisión de arquitectura; aprobación del diseño con firma del ingeniero de seguridad | Ingeniero de seguridad / Líder de desarrollo |
| Codificación segura | Adoptar y aplicar un estándar de codificación segura (p. ej., OWASP ASVS, SEI CERT) | Documento del estándar de codificación segura; resultados de análisis SAST vinculados a commits; registros de revisión de código | Líder de desarrollo |
| Pruebas de seguridad en el desarrollo | Integrar las pruebas de seguridad en el pipeline de desarrollo | Informes de análisis SAST/DAST vinculados a IDs de compilación; plan de pruebas con casos de prueba de seguridad; registros de aprobación/rechazo | Líder de QA / Líder de DevOps |
| Desarrollo externalizado | Aplicar requisitos de seguridad al código de terceros y externalizado | Cláusulas de seguridad del proveedor en los contratos; evidencia de revisión de código del proveedor o resultados de SAST | Responsable de proveedores / Gestor del SGSI |
| Separación de entornos de desarrollo, prueba y producción | Garantizar el aislamiento de entornos; prohibir el uso de datos de producción en entornos de prueba | Diagrama de topología de entornos; registros de control de acceso; registros de anonimización de datos de prueba | Líder de DevOps |
| Gestión de cambios | Controlar los cambios en los sistemas mediante un proceso formal | Registros de solicitudes de cambio con aprobaciones; registros de puertas de aprobación del pipeline; procedimientos de reversión | Líder de desarrollo / Gestor de cambios |
| Información de prueba | Proteger los datos de prueba; evitar el uso de datos personales reales en las pruebas | Política de datos de prueba; registros de anonimización o generación de datos sintéticos | Líder de QA / Delegado de Protección de Datos |
| Protección de los sistemas de información durante las pruebas de auditoría | Restringir y registrar el acceso durante las auditorías o pruebas de penetración | Acuerdo de alcance de la prueba de penetración; registros de acceso durante la ventana de prueba; informe de hallazgos con plan de remediación | Gestor del SGSI / Ingeniero de seguridad |
| Seguridad de la información para servicios en la nube | Aplicar requisitos de seguridad a los entornos de desarrollo alojados en la nube | Acuerdo de servicio en la nube con cláusulas de seguridad; matriz de responsabilidad compartida | Gestor del SGSI / Responsable de proveedores |
| Gestión de vulnerabilidades técnicas | Mantener un proceso de gestión de vulnerabilidades que cubra los productos del SDLC | Registro de clasificación de vulnerabilidades con fechas y severidad; registros de SBOM; tickets de remediación con seguimiento de SLA | Ingeniero de seguridad |
| Gestión de la configuración | Gestionar configuraciones seguras para las herramientas e infraestructura de desarrollo | Documentos de línea base de configuración; plantillas de IaC con control de versiones; registros de detección de desviaciones | Líder de DevOps |
El grupo de controles AppSec requiere un procedimiento documentado, un responsable nominado y una muestra de evidencias que cubra al menos un período de auditoría (normalmente entre 3 y 12 meses). Los controles A.8.25, A.8.26, A.8.27 y A.8.28 tienen propósitos distintos y deben abordarse de forma explícita aunque se implementen mediante un único documento de procedimiento.
Evidencias mínimas que suelen aceptar los auditores:
- Resultados de SAST vinculados a Git que muestran el hallazgo, el hash del commit y la fecha de remediación
- Registros de SBOM generados por versión con marcas de tiempo
- Registros de puertas de aprobación del pipeline que acreditan la finalización de la fase de seguridad obligatoria
- Registros de aislamiento de entornos o registros de control de acceso
- Tickets de clasificación de vulnerabilidades con severidad, fecha de apertura y fecha de cierre
¿Cómo se recopilan y presentan las evidencias para cada elemento de la lista?
Los auditores se centran en la trazabilidad: un control nominado, una evidencia y una fecha. Las descripciones de procesos abstractas no son suficientes. Cada elemento de la lista de verificación debe generar entre 3 y 5 artefactos reproducibles.
Política de desarrollo seguro: El documento de política necesita un nombre de responsable, una fecha de aprobación, un número de versión y una fecha de revisión. Almacénelo en su sistema de gestión documental con un historial de versiones. La convención de nomenclatura SDev-Policy-v1.2-2025-09-01.pdf permite al auditor identificar la fecha y la versión de un solo vistazo.
Separación de entornos: Un diagrama de topología por sí solo no es suficiente. Complételo con registros de control de acceso que demuestren que no existen cuentas de desarrollador en producción, y un registro fechado de cualquier excepción con una aprobación de aceptación de riesgo. Los pipelines de CI/CD deben aplicar fases obligatorias de pruebas de seguridad, puertas de aprobación y registros de auditoría inmutables para cumplir los subcontroles de A.14; esos registros del pipeline sirven como registro inmutable.
Registros de clasificación de vulnerabilidades (A.8.8): Una hoja de cálculo sin fechas es una señal de alerta. Utilice su sistema de seguimiento de incidencias (Jira, Linear o equivalente) para que cada hallazgo tenga una marca de tiempo de creación, severidad, asignado y fecha de cierre. Exporte una vista filtrada que cubra el período de auditoría como artefacto de evidencia.
| Artefacto | Metadatos requeridos | Ubicación de almacenamiento | Método de verificación del auditor |
|---|---|---|---|
| Política de desarrollo seguro | Responsable, versión, fecha de aprobación, fecha de revisión | Sistema de gestión documental (con control de versiones) | Verificar historial de versiones; confirmar autoridad del firmante |
| Informe de análisis SAST | ID de compilación, hash del commit, nombre de la herramienta, fecha del análisis, número de hallazgos | Almacén de artefactos de CI/CD (inmutable) | Cruzar el hash del commit con el control de código fuente |
| Archivo SBOM | Versión de la release, fecha de generación, nombre de la herramienta, lista de componentes | Registro de artefactos o almacenamiento seguro de archivos | Verificar que la fecha de generación coincide con la fecha de la release |
| Registro de clasificación de vulnerabilidades | ID del hallazgo, severidad, fecha de apertura, asignado, fecha de cierre | Sistema de seguimiento de incidencias (Jira, Linear, etc.) | Filtrar por período de auditoría; verificar el cumplimiento del SLA |
| Registro de acceso al entorno | Usuario, acción, marca de tiempo, nombre del entorno | SIEM o servicio de registro de acceso en la nube | Confirmar que no existe acceso entre entornos sin aprobación |
Consejo profesional: Los auditores solicitan cada vez más evidencias vinculadas a Git en lugar de informes periódicos. Configure su pipeline de CI/CD para adjuntar el informe SAST como artefacto de compilación con el SHA del commit incluido en el nombre del archivo. Ese único paso elimina la impugnación de autenticidad de evidencias más frecuente.
¿Quién es responsable de qué? Gobernanza de los controles del SDLC en el SGSI
La rendición de cuentas clara es lo que distingue un SGSI operativo de un mero ejercicio de cumplimiento. El modelo de gobernanza que se presenta a continuación asigna roles entre las seis funciones que los auditores esperan encontrar.
| Área de control | Responsable del SGSI | Propietario del control | Líder de desarrollo | Ingeniero de seguridad | Líder de QA | Responsable de proveedores |
|---|---|---|---|---|---|---|
| Política de desarrollo seguro | A (Aprueba) | R (Responsable) | C (Consultado) | C | I (Informado) | I |
| Requisitos de seguridad | I | C | R | C | C | C |
| Arquitectura segura | I | C | C | R | I | I |
| Estándar de codificación segura | I | C | R | R | C | C |
| Pruebas de seguridad | I | C | C | C | R | I |
| Desarrollo externalizado | A | R | I | C | I | R |
| Separación de entornos | I | C | R | C | I | I |
| Gestión de vulnerabilidades | I | R | C | R | C | C |
Las aprobaciones ejecutivas requeridas incluyen: aprobación inicial de la política por parte del responsable del SGSI, firma de la Declaración de Aplicabilidad que confirme la aplicabilidad y justificación de cada control, y una revisión de dirección anual que muestree evidencias del período anterior. La frecuencia de muestreo de evidencias debe ser al menos trimestral para los controles de alto riesgo (A.8.28, A.8.29, A.8.8) y semestral para los de menor riesgo.
¿Cuánto tiempo lleva implementar los controles del SDLC y cuánto cuesta?
El esfuerzo varía según la madurez. La tabla siguiente ofrece rangos realistas para una organización que implemente los controles del SDLC como parte de un proyecto más amplio de ISO 27001.
| Nivel de madurez | Fase | Duración típica | Perfil de recursos |
|---|---|---|---|
| Mínimo (procesos ad hoc, sin política formal de SDLC) | Redacción de políticas y mapeo de la Declaración de Aplicabilidad | 3–4 semanas | — |
| Mínimo | Configuración de herramientas (SAST, SBOM, puertas de pipeline) | 4–6 semanas | 1 FTE DevOps + — |
| Moderado (algunas políticas existen, evidencias inconsistentes) | Remediación de brechas y recopilación de evidencias | 4–6 semanas | — |
| Moderado | Auditoría interna y revisión previa a la auditoría | 2–3 semanas | 0,5 FTE Gestor del SGSI |
| Completo (DevSecOps maduro, controles documentados) | Empaquetado de evidencias y finalización de la Declaración de Aplicabilidad | 2–3 semanas | 0,25 FTE Gestor del SGSI + 0,25 FTE Líder de desarrollo |
Un desglose de Gantt de muestra para el flujo de trabajo del SDLC en una organización de madurez moderada: semanas 1–3 para la redacción de políticas y procedimientos; semanas 4–8 para la integración de herramientas y la configuración de puertas de aprobación del pipeline; semanas 9–12 para la recopilación de evidencias durante un período de auditoría de muestra; semanas 13–14 para la auditoría interna de evidencias y el cierre de brechas; semana 15 para la actualización de la Declaración de Aplicabilidad y la preparación de la auditoría.
Consejo profesional: Ejecute la verificación de preparación de 2 minutos de Ismscalculator antes de comprometerse con un plazo. Esta herramienta mapea su madurez actual en los cuatro temas de control de ISO/IEC 27001:2022 e identifica qué controles del SDLC consumirán más esfuerzo, para que pueda priorizar el trabajo adecuado desde el principio.
La evaluación completa de preparación convierte esos rangos de esfuerzo en una estimación de costes personalizada y un diagrama de Gantt descargable, que es exactamente lo que necesita para una conversación de aprobación de presupuesto.
¿Dónde puede obtener una plantilla de lista de verificación y adaptarla a su organización?
Una plantilla práctica de lista de verificación para este conjunto de controles debe contener las siguientes columnas: cláusula ISO, tarea de la lista de verificación, tipo de artefacto de evidencia, convención de nomenclatura del artefacto, rol responsable, estado actual (No iniciado / En curso / Completado) y un enlace al artefacto de muestra.
Pasos de adaptación según el tipo de organización:
- Empresas SaaS y tecnológicas: Añada una columna para la fase del pipeline de CI/CD donde se aplica cada control. La guía ISO 27001 para empresas SaaS y tecnológicas incluye plantillas específicas del SDLC y notas de implementación directamente aplicables aquí.
- Sectores regulados (finanzas, sanidad): Cruce cada control del SDLC con los requisitos específicos de su sector (SOC 2, HIPAA, PCI DSS). La comparación de estándares de seguridad de datos financieros mapea los controles de ISO 27001 con las regulaciones financieras.
Consejo profesional: Mantenga su lista de verificación en un documento con control de versiones (Confluence, Notion o un archivo markdown alojado en Git). Cada cambio de estado se convierte automáticamente en un registro de auditoría fechado, y puede exportar una instantánea para el auditor sin necesidad de crear un paquete de evidencias independiente.
Esqueletos de políticas, plantillas de SBOM de muestra y fragmentos de planes de prueba están disponibles a través de la guía de controles del Anexo A de ISO 27001 de Ismscalculator, que mapea cada control con elementos prácticos de evidencia.
Conclusiones clave
Una lista de verificación de seguridad del SDLC auditable requiere un responsable nominado, un artefacto fechado y un vínculo trazable entre cada control del Anexo A de ISO 27001 y su evidencia antes de que comience la Fase 2.
| Punto | Detalles |
|---|---|
| Mapee cada control del SDLC de forma explícita | Liste A.8.25–A.8.34, A.5.23, A.8.8 y A.8.9 individualmente en su Declaración de Aplicabilidad con un procedimiento y evidencia para cada uno. |
| Vincule las evidencias a compilaciones y commits | Adjunte los informes SAST y los SBOM a los IDs de compilación y hashes de commit para que los auditores puedan verificar su autenticidad. |
| Asigne responsables nominados, no equipos | Cada procedimiento y elemento de la lista de verificación necesita un título de rol específico como responsable, no «el equipo de desarrollo». |
| Realice primero una prueba de trazabilidad interna | Seleccione una compilación aleatoria y rastréela a través de SAST, la puerta de aprobación, el SBOM y los registros de clasificación antes de la Fase 2. |
| Utilice Ismscalculator para la planificación del esfuerzo | La verificación de preparación y la evaluación completa convierten las brechas en los controles del SDLC en un plazo presupuestado y una exportación de Gantt. |
Lo que la mayoría de los equipos hace mal con los controles del SDLC
La mayoría de las organizaciones dedican sus dos primeros meses a redactar políticas y casi nada a la infraestructura de evidencias. Ese es el orden incorrecto. Una política de desarrollo seguro impecable sin resultados de SAST vinculados al pipeline ni SBOM fechados producirá una no conformidad mayor en la Fase 2, independientemente de lo bien redactado que esté el documento.
Los controles que más problemas generan a los equipos no son los más complejos. A.8.31 (separación de entornos) y A.8.8 (gestión de vulnerabilidades) fallan constantemente en las auditorías, no porque los controles sean difíciles de implementar, sino porque las evidencias están dispersas o sin fecha. Corrija la cadena de evidencias antes de perfeccionar el texto de las políticas.
Una prioridad práctica: automatice la generación del SBOM en el momento de la release, no como una tarea manual trimestral. Un SBOM fechado por release, almacenado junto con el artefacto de la release, satisface los requisitos de evidencia de A.8.8 y le proporciona un registro de auditoría de dependencias que cubre múltiples controles simultáneamente. Ese único paso del pipeline rinde frutos en al menos cuatro elementos de la lista de verificación.
Ismscalculator convierte esta lista de verificación en un presupuesto y un plan de proyecto
Mapear los controles del SDLC a ISO 27001 es una cosa. Saber cuánto le costará a su organización y cuánto tiempo llevará es lo que consigue que un proyecto sea aprobado.
Ismscalculator toma el tamaño de su empresa, el sector y la madurez de seguridad actual y genera una estimación de costes y esfuerzo personalizada para su implementación completa de ISO 27001, incluido el flujo de trabajo de controles del SDLC. La plataforma cubre los cuatro temas de control de ISO/IEC 27001:2022, genera un diagrama de Gantt personalizable que puede compartir con las partes interesadas y exporta un informe en PDF diseñado para conversaciones de aprobación de presupuesto. La verificación de preparación de 2 minutos le ofrece una instantánea instantánea de su madurez sin coste alguno. Cuando esté listo para profundizar, la evaluación completa de preparación para ISO 27001 convierte las brechas de su lista de verificación en un plan de proyecto por fases con comparaciones de referencia para que sepa exactamente dónde se encuentra.
Fuentes útiles y lecturas adicionales
Las fuentes siguientes respaldan secciones específicas de esta lista de verificación. Úselas para verificar el texto de las cláusulas, revisar las expectativas de los auditores y adaptar la lista a su entorno.
- ISO 27001 Application Security: Annex A Controls Guide (2022)
- ISO 27001 Application Security: Full Control Mapping
- ISO 27001 Secure SDLC: Key Requirements, Steps, and Templates (2026) | Konfirmity
- ISO 27001 A.14 Deep Dive — System Development and Maintenance in CI/CD - Regulated DevSecOps
- ICT Institute | ISO 27001 technological controls for software development
- Free ISO 27001 Readiness Check — 2-Minute Self-Assessment | ISMS Calculator
- ISO 27001 for SaaS & Tech Companies: A Practical Guide | ISMS Calculator