Durante parte del año 2024 y todo el año 2025 se ha venido desarrollando una actualización importante del estándar de software seguro del PCI (PCI Secure Software Standard) que ha culminado en su publicación el 15 de enero de 2026 bajo la versión 2.0.
Esta nueva versión elimina el término “Aplicación de Pago” para referirse a un nuevo contexto llamado “Activos Sensibles”, donde dichos activos deben documentarse de forma precisa y exhaustiva. Para facilitar este proceso, se introduce un nuevo documento llamado “PCI Sensitive Assets Identification - For use with the PCI Secure Software Standard v2.x”, que proporciona las definiciones y categorizaciones de activos sensibles a las que estándar de aplicaciones seguras hace referencia incluyendo algunos ejemplos, y un apéndice (Appendix A) a modo de plantilla opcional que pueden utilizar los proveedores de desarrollo de software seguro para proporcionar toda la información que sí es obligatoria disponer durante el proceso de auditoría.
El segundo documento es el estándar mismo: PCI Secure Software Standard, v2.0, que incorpora requisitos nuevos y otros actualizados. Los siguientes son los mayores cambios que encontramos en esta nueva versión:
◾Se ha eliminado el contexto de «aplicación de pago».
◾Se ha rediseñado el contexto de los activos sensibles.
◾Los requisitos de prueba se han reescrito y ahora tienen una alta dependencia de la revisión de documentación, las pruebas estáticas y dinámicas.
◾Se han actualizado algunas definiciones importantes.
◾Se cambia el término “Objetivos de Control” por “Objetivos de Seguridad” que en sí nos trae un cambio de filosofía del estándar.
◾Se ha añadido un nuevo módulo para las aplicaciones de tipo SDK y se convierte en una alternativa para la certificación de SDKs 3DS, actualizándose el documento PCI 3DS Data Matrix a la versión 1.2.
◾Se pide un nuevo listado que hace referencia a la identificación de operaciones sensibles.
◾Se requiere tener lista de materiales de aplicación y sus dependencias (SBOM).
◾Ahora la autenticación multi-factor (MFA) es obligatoria para las operaciones sensibles.
◾Se pide una mayor granularidad en los logs generados.
◾Si los logs se exportan deben estar cifrados.
◾Se deben generar logs de eventos sospechosos y deben estar cifrados.
◾Se introducen cambios en el contenido esperado en la guía de implementación.
◾Se eliminaron redundancias dentro de la propia norma, entre los módulos y el cuerpo principal y también entre el estándar de aplicaciones seguras y el estándar de ciclo de vida.
◾Se eliminaron todas las expresiones que constituyen requisitos de seguridad, de la sección donde se referenciaban las pruebas necesarias para demostrar cumplimiento.
◾Se ha hecho un cambio en la redacción de los requisitos con el objetivo de mejorar el grado de objetividad de los requisitos de seguridad.
◾Se reestructuró la organización y el flujo del estándar, especialmente el cuerpo principal.
◾Se ha aumentado la asociación entre PAN/SAD en este estándar con PCI DSS.
◾Se ha incluido el glosario como parte del estándar.
◾Se ha dado marcha atrás en la eliminación de los comodines en el manejo de versiones y vuelven a ser aceptados para cambios que no impactan en la seguridad.
◾De igual manera ahora, nuevamente se pueden tener evaluaciones delta para cambios significativos y se actualiza la plantilla de impacto del cambio.
◾Se dan algunos beneficios adicionales para las entidades certificadas en SLC en términos de las validaciones anuales para algunos tipos de cambios.
En referencia a otros elementos que requieren actualización y que determinan cómo será la transición, se ha informado que la documentación de soporte (ROV, AOV) será publicada en febrero de 2026, la formación CBT (Computer-Based Training) será actualizada durante el primer trimestre de este año y la formación con instructor será actualizada durante el segundo trimestre. Una vez se haya publicado la formación, se dará una ventana de 12 meses de transición entre la versión 1.2.1 y la versión 2.0.
Una mirada rápida del estándar nos presenta una redistribución de los requisitos en 11 objetivos de seguridad y 4 módulos cada uno de ellos con sus respectivos objetivos de seguridad.
Los objetivos de seguridad según la nueva distribución son:
| Core | All Software |
| Security Objective 1 | Software Architecture, Composition, and Versioning |
| Security Objective 2 | Sensitive Asset Identification |
| Security Objective 3 | Sensitive Asset Storage and Retention |
| Security Objective 4 | Sensitive Modes of Operation |
| Security Objective 5 | Sensitive Asset Protection Mechanisms |
| Security Objective 6 | Sensitive Asset Output |
| Security Objective 7 | Random Numbers |
| Security Objective 8 | Key Management |
| Security Objective 9 | Cryptography |
| Security Objective 10 | Threats and Vulnerabilities |
| Security Objective 11 | Secure Deployment and Management |
| Module A | Account Data Protection |
| Security Objective 1A | Securing Account Data |
| Module B | POI Device Software |
| Security Objective 1B | PTS Approval |
| Security Objective 2B | Approved POI Device Functionality |
| Security Objective 3B | Authentication |
| Module C | Publicly-accessible Software |
| Security Objective 1C | HTTP Headers |
| Security Objective 2C | Input Protection Mechanisms |
| Security Objective 3C | Session Management |
| Security Objective 4C | User Authentication |
| Module D | Software Development Kits |
| Security Objective 1D | SDK Integrity |
Este nuevo estándar es una evolución que da claridad y elimina redundancias en los diferentes requisitos además de incorporar algunos elementos que requieren las aplicaciones en los entornos actuales. Aunque aún no se tienen fechas concretas para que esta nueva versión empiece a ser obligatoria, sí tenemos un horizonte de tiempo que nos lleva a entender que más o menos en 18 meses se habrá terminado la transición; por esta razón se deben analizar los cambios ya que las aplicaciones deberán ser actualizadas para incorporar la alineación con los nuevos requisitos y una actualización de la guía de implementación, significando esto hacer un análisis de brechas lo antes posible ya que dichos cambios pueden requerir tiempos y recursos importantes para su desarrollo.