Formación específica por lenguaje, mapeada por rol y práctica, con evidencia por desarrollador que su QSA aceptará a la primera, en el primer ciclo.
El Requisito 6.2.2 enuncia elementos clave: contenido específico por lenguaje, relevancia por función laboral, práctica práctica y evidencia por desarrollador. Nuestra plataforma se diseñó para satisfacer cada uno, no adaptada a posteriori sobre una videoteca.
Cada desafío, ejemplo y corrección presentados en el lenguaje que su desarrollador realmente utiliza: JavaScript, TypeScript, Python, Java, C#, Go, Swift, Kotlin, PHP, Ruby, Rust y más. Sin pseudocódigo. Sin descargos del tipo «los principios se transfieren».
Asigne rutas distintas por rol: ingenieros de backend en servicios de pago, ingenieros de frontend en la interfaz de checkout, ingenieros móviles en aplicaciones de wallet. Los responsables de seguridad controlan el mapeo. Los desarrolladores solo ven lo que su rol requiere.
Los desarrolladores producen resultados: clasifican código vulnerable, escriben correcciones y revisan pull requests con fallos plantados. La evaluación está integrada en cada desafío. El consumo pasivo de vídeos no es nuestra arquitectura; lo es la capacidad demostrada.
Exportaciones del sistema de registro: por alumno, por módulo, con marcas de tiempo, puntuaciones y número de intentos. Informe de vigencia frente a la ventana móvil de 12 meses. El conjunto exacto de artefactos que su QSA solicita, listo desde el primer día.
Un QSA que aborda una revisión de evidencias del 6.2.2 busca siete artefactos concretos. Nuestra plataforma produce los siete, de forma automática, continua y en los formatos que los evaluadores leen.
Descripción del currículo generada automáticamente por lenguaje y rol, con control de versiones y un registro de cambios que el QSA puede inspeccionar.
Listado actualizado de cada desarrollador dentro del alcance con su ruta de currículo asignada. Se sincroniza con su RRHH o SSO para que los cambios de rol se actualicen automáticamente.
Cada módulo registrado: fecha de finalización, puntuación, intentos y remediación. Exportaciones en CSV y PDF. Trazabilidad por alumno, lista para adjuntar al ROC.
Fecha de formación más reciente de cada desarrollador, estado de la ventana móvil de 12 meses y próximas caducidades señaladas 60 y 30 días antes del vencimiento.
Seguimiento de módulos separado para la formación en el uso de herramientas SAST, DAST, SCA e IAST: la cláusula condicional que la mayoría de los programas se olvida de evidenciar.
Currículo mapeado a las categorías de ataque del 6.2.4 y al OWASP Top 10. Brechas identificadas con un plan de remediación documentado y un calendario.
Evidencia de la revisión anual del currículo: actualizaciones vinculadas a nuevas clases de ataque, datos de incidentes internos y comentarios de los desarrolladores.
El texto del requisito es breve. El trabajo de evaluación no lo es. Estos son los patrones que observamos cuando los QSA realmente se sientan a evidenciar un programa de 6.2.2 en el ciclo de 2026.
Un QSA que examina el 6.2.2 quiere tres hilos documentales. El primero es la asignación: quién está dentro del alcance, qué se le asignó y cómo se decidió el mapeo de roles a currículo. El segundo es la finalización: registros por desarrollador con marcas de tiempo, puntuaciones o estado de aprobado, y la versión del contenido completado. El tercero es la vigencia del contenido: evidencia de que el currículo refleja las clases de vulnerabilidad actuales y que las actualizaciones de material se han incorporado desde la evaluación anterior.
Un programa que produce un único informe anual de finalización a nivel de equipo tendrá dificultades. Un programa que exporta registros por alumno con referencias de contenido con marca de versión no las tendrá. El listón no es cuánta formación impartió, sino con qué claridad puede demostrar que determinados desarrolladores completaron determinado contenido dentro de la ventana móvil de doce meses.
Estos dos requisitos se confunden con frecuencia. No deberían hacerlo. El Requisito 12.6.1 es formación general de concienciación en seguridad para todo el personal: phishing, higiene de contraseñas, seguridad física, notificación de incidentes. La audiencia es cualquier persona con acceso a datos de titulares de tarjeta o a sistemas que los tratan, con independencia del rol. El Requisito 6.2.2 es formación en código seguro específicamente para el personal de desarrollo de software, con las características —específica por lenguaje, relevante por rol y práctica— enunciadas en el propio requisito.
SecureCodingHub aborda el 6.2.2. No satisface el 12.6.1 por sí solo, y no lo comercializamos como una plataforma de concienciación general. Un programa que utiliza un proveedor de concienciación de 12.6.1 para la población más amplia y SecureCodingHub para la población de desarrolladores cubre ambos requisitos sin obligar a una herramienta a hacer un trabajo para el que no fue creada.
El error de alcance más frecuente es formar únicamente a los ingenieros que poseen servicios orientados a producción y excluir a equipos adyacentes. Los desarrolladores que escriben herramientas internas, procesos por lotes, código de integración o bibliotecas compartidas que fluyen hacia el entorno de datos de titulares de tarjeta siguen estando dentro del alcance del 6.2.2 cuando su código puede afectar a ese entorno. El alcance se determina por los sistemas a los que toca el código, no por el lugar que ocupa el ingeniero en el organigrama.
El segundo error es excluir a contratistas y personal de ingeniería temporal. Si un contratista publica código que se ejecuta en el CDE, está dentro del alcance. La relación contractual no cambia el requisito. Un programa limpio dispone de un único listado que cubre a empleados y contratistas, con la misma lógica de asignación de currículo aplicada a ambos.
El tercero es tratar la formación como un evento anual. La ventana móvil de doce meses de vigencia es implacable. Un desarrollador que completó el currículo trece meses antes de la evaluación no cumple para ese ciclo de evaluación aunque hubiera estado plenamente formado el año anterior. Los programas que planifican la formación como una campaña anual tienden a perder la vigencia para nuevas incorporaciones y cambios de rol. La asignación continua con re-formación automática en el límite de los doce meses es el único patrón que sobrevive a un segundo ciclo sin intervención.
Una llamada de treinta minutos suele bastar para saber si encajamos en su ciclo de 2026. Recorremos con su equipo el listón del 6.2.2, mapeamos nuestro programa a su stack y le mostramos el paquete de evidencias que su QSA ya ha visto funcionar.