ISO/IEC 27001:2022 introdujo A.8.28 Codificación segura como un nuevo control. Forme a sus desarrolladores frente a él, evidéncielo limpiamente para auditores internos y externos y cierre la brecha de transición de 27001:2013 a 27001:2022 antes de su próxima visita de seguimiento.
La revisión 27001:2022 reestructuró el Anexo A y añadió la codificación segura como control explícito. Nuestra plataforma se diseñó en torno al nuevo conjunto de controles —A.8.28, A.6.3, A.8.29 y A.5.7—, no adaptada a posteriori sobre un LMS genérico.
A.8.28 será lo primero que los auditores busquen en este ciclo. Hacemos el mapeo directamente: currículo de código seguro específico por lenguaje en más de 15 stacks, cobertura de categorías de vulnerabilidad alineada con OWASP y prueba demostrada de competencia por desarrollador, no asistencia.
A.6.3 abarca la concienciación del personal de forma más amplia, y los equipos de ingeniería necesitan una vía específica para desarrolladores que la satisfaga de manera creíble. Rutas mapeadas por rol para ingenieros de backend, frontend y móvil, distintas de la concienciación general en seguridad, cierran esa brecha con registros auditables.
A.8.29 exige pruebas de seguridad dentro del SDLC. La formación cubre lo que los desarrolladores deben ejecutar antes del merge: patrones de integración de SAST, DAST e IAST, escaneo de dependencias y cómo clasificar los hallazgos, de modo que el control se operacionalice y no se quede solo en el papel.
A.5.7 es una adición de 27001:2022 que los auditores aún están aprendiendo a evidenciar. Nuestra actualización trimestral del currículo realiza el seguimiento de las clases de vulnerabilidad emergentes —patrones de día cero, confusión de dependencias, CVE recientes—, de modo que la inteligencia de amenazas sea una entrada viva en la formación, no una diapositiva obsoleta.
Un auditor interno o un evaluador del organismo de certificación que entra en una revisión de A.8.28 busca un conjunto específico de artefactos. Nuestra plataforma produce los siete, de forma automática, continua y en los formatos que los auditores del SGSI esperan.
Cada transcripción mapeada a los controles A.8.28 y A.6.3 con marcas de tiempo, puntuaciones e historial de intentos. El registro exacto por alumno que un auditor rastrea desde un desarrollador muestreado.
Descripción del currículo vinculada a los lenguajes, frameworks y categorías OWASP dentro del alcance de su SGSI, con control de versiones y un registro de cambios que el auditor puede inspeccionar.
Puntuación sobre capacidad demostrada —clasificar código vulnerable, escribir correcciones, revisar pull requests con fallos plantados—, no tiempo de asiento. La forma de competencia que A.6.3 realmente pide.
Resultado de la formación vinculado al gancho de A.8.29: desarrolladores formados en la ejecución de SAST, DAST, IAST y verificaciones de revisión de código antes del merge, con la finalización del módulo vinculada a esas actividades.
Registros de actualización vinculados a entradas de inteligencia de amenazas (A.5.7) —clases de vulnerabilidad emergentes, riesgos de cadena de dependencias, CVE recientes— con justificación documentada para cada cambio del currículo.
Exportaciones en CSV y JSON con referencias a controles incluidas —A.8.28, A.6.3, A.8.29, A.5.7—, de modo que el auditor lea la alineación con los controles sin tener que traducir desde la taxonomía de su LMS.
Texto listo para insertar en la SoA para los controles del Anexo A dentro del alcance, citando esta formación como mitigación principal, junto con las referencias de evidencia que su evaluador muestreará.
Una llamada de treinta minutos suele bastar para saber si encajamos en su SGSI. Recorremos con su equipo el listón de A.8.28, mapeamos nuestro programa a su stack y a su SoA, y le mostramos el paquete de evidencias que auditores internos y externos ya han aceptado.
Cualquier organización que maneje datos sensibles de clientes, procese pagos o venda en mercados regulados (finanzas, sanidad, sector público, alcance de EU CRA) suele necesitar un SGSI ISO 27001. Los equipos de ingeniería dentro de organizaciones certificadas necesitan la formación en código seguro de A.8.28 y la formación de concienciación de A.6.3 que un auditor pueda muestrear, independientemente del tamaño de la empresa.
La revisión de 2022 reestructuró el Anexo A pasando de 114 controles a 93 agrupados en cuatro temas, y añadió 11 controles nuevos, entre ellos A.8.28 Codificación segura, A.5.7 Inteligencia de amenazas y A.5.23 Seguridad de la información para servicios en la nube. La fecha límite de transición de 27001:2013 a 27001:2022 es el 31 de octubre de 2025, por lo que la mayoría de las organizaciones ya están en su primer ciclo de seguimiento frente al nuevo conjunto de controles.
A.6.3 cubre la concienciación general del personal —phishing, higiene de contraseñas, uso aceptable—, que la mayoría de las plataformas de concienciación ya ofrecen. A.8.28 es específico de ingeniería y pide competencia demostrada en codificación segura. La formación de concienciación en seguridad ISO 27001 por sí sola no satisface A.8.28; los auditores esperan una vía separada para desarrolladores con un currículo mapeado por rol y evidencia de evaluación por alumno.
La formación en sí no es una certificación: lo que se certifica es su SGSI. Pero las transcripciones por desarrollador, los resultados de evaluación de competencia y el mapeo de currículo a controles que esta plataforma produce son los artefactos que un evaluador externo del organismo de certificación pedirá al auditar A.8.28 y A.6.3 durante la certificación inicial o las auditorías de seguimiento.