Insights | Integrity360

Norma de software seguro de la PCI v2.0: Un análisis exhaustivo de la revisión principal

Escrito por Alessandro Amalfitano | 02-feb-2026 12:23:23

El PCI Security Standards Council ha publicado la versión 2.0 del Estándar de Software Seguro y la Guía del Programa que lo acompaña, lo que supone la revisión más importante desde la creación del marco en 2019. Esta actualización remodela fundamentalmente la forma en que se evalúa y valida el software de pago, introduciendo nueva terminología, un alcance ampliado y procesos simplificados que impactarán a proveedores, evaluadores y clientes en todo el ecosistema de pagos.

La base: Un nuevo enfoque de la elegibilidad y el alcance

Quizá el cambio más fundamental de la versión 2.0 sea la eliminación completa del término "software de pago" de la norma. Los criterios de elegibilidad se centran ahora por completo en el concepto de Sensitive Assets, definidocomo cualquier elemento del producto de software cuyo acceso, uso, modificación o divulgación no autorizados puedan poner en peligro la funcionalidad o los datos relacionados con los pagos del software.

Este replanteamiento conceptual va acompañado de un nuevo documento complementario obligatorio, Sensitive Asset Identification (SAID), que proporciona un contexto detallado y ejemplos para identificar datos, funcionalidades, recursos y modos de operación sensibles. Para los datos relacionados con EMVCo 3DS, la norma hace ahora referencia al documento PCI 3DS Data Matrix.

La implicación práctica es clara: si su software maneja activos sensibles según la definición de la norma, entra dentro de su ámbito de aplicación, independientemente de si encaja o no en las categorías tradicionales de software de pago.

Revisión terminológica: Comprender el nuevo lenguaje

La versión 2.0 introduce importantes actualizaciones terminológicas que los evaluadores y proveedores deben interiorizar:

Además, el glosario se ha trasladado de un documento SSF externo a Apéndice A de la propia norma, con términos definidos ahora marcados a lo largo de los requisitos de seguridad para facilitar su reconocimiento. Se ha introducido un nuevo término, "Autenticación robusta", , y la norma se basa ahora en la línea de base de "Criptografía robusta" en lugar de parámetros específicos de fuerza de clave efectiva.

 

Reorganización estructural: Requisitos básicos y módulos

La norma v2.0 se ha reestructurado por completo en torno a once objetivos de seguridad en la sección principal, que se aplica a todo el software evaluado con arreglo al marco:

  1. Arquitectura, composición y versionado del software - Incluye nuevos requisitos para la lista de materiales (BOM) y el versionado comodín.
  2. Identificación de activos sensibles - Establece las bases para los requisitos posteriores.
  3. Almacenamiento y conservación de activos sensibles
  4. Modos sensibles de operación - Contexto formalizado para el control de acceso y la autenticación fuerte
  5. Protección de activos sensibles - Incluye la detección formalizada de comportamientos anómalos
  6. Salida de activos sensibles - Con requisitos formalizados de canal seguro
  7. Números aleatorios - Requisitos refinados para el uso de RNG externos o la implementación interna
  8. Gestión de claves
  9. Criptografía - Un único requisito que engloba áreas no cubiertas en otros apartados
  10. Amenazas y vulnerabilidades
  11. Despliegue y gestión seguros - Con requisitos de orientación para la implantación

 

Evolución del módulo: Cambios

Módulo A - Protección de datos de cuentas

Los requisitos se han revisado para centrarse únicamente en PAN y SAD en relación con PCI DSS, con contexto adicional proporcionado en el documento SAID.

Módulo B - Software de dispositivos PDI

Renombrado de "Requisitos del software del terminal", este módulo se ha simplificado considerablemente. Muchos requisitos (B1.1, B1.2, B1.3, B3.x, B5.x) se han integrado en los requisitos básicos, y se han revisado los requisitos SRED.

Módulo C - Software de acceso público

Se ha cambiado el nombre de "Requisitos del software web" para reflejar mejor su objetivo. La aclaración del ámbito de aplicación es significativa: este módulo aborda el software accesible a través de redes públicas en las que básicamente cualquier persona con acceso a la red puede interactuar con el software. Es importante destacar que el software que es no accesible al público todavía puede ser evaluado para este módulo a discreción del proveedor, ya que los requisitos ayudan a reducir el riesgo de cualquier implementación.

Módulo D - Kits de desarrollo de software (NUEVO)

Este módulo totalmente nuevo permite evaluar los SDK, incluido EMVCo 3DS SDKs. La norma establece explícitamente que la versión 2.0 sustituirá con el tiempo a la norma independiente PCI 3DS SDK, ofreciendo a los vendedores una mayor flexibilidad gracias a la naturaleza más objetiva de la norma de software seguro.

 

Cambios en Delta: El nuevo sistema de niveles

Las anteriores categorías de cambios de "bajo impacto" y "alto impacto" se han sustituido por una estructura decambios Delta denivel 1 y 2 :

Cambios Delta de Nivel 1

  • Cambios que no afectan a la seguridad, en los que los números de versión deben cambiar pero no se utilizan comodines.
  • Losproveedores calificados por SSLC se benefician: las correcciones/parches de errores que afectan a la seguridad, incluso si afectan a activos sensibles, se califican como de nivel 1 y pueden ser autopresentados sin la participación del evaluador.

 

Nivel 2 Delta Cambios

  • Introducción de nuevos tipos de activos sensibles
  • Cambios que requieren la evaluación de requisitos no evaluados previamente
  • Cambios que impliquen o afecten a activos sensibles (excepto los cambios admisibles de nivel 1 para proveedores de SSLC)
  • Cambios en los dispositivos PTS POI
  • Modificación de las dependencias requeridas
  • Eliminación de versiones específicas de los listados

 

Comodines: Formalización y reintroducción

Se ha reintroducido formalmente el uso de comodines con reglas claras:

  • Definición: Carácter que puede sustituir a un subconjunto definido de caracteres posibles en un sistema de versiones para tener en cuenta cambios que no afectan a la seguridad.
  • Los comodines deben aparecer sólo en la parte derecha (menos significativa) de los números de versión.
  • Caracteres comodín permitidos: minúsculas {x, y, z}, mayúsculas {X, Y, Z}, o asterisco (*)
  • Un solo comodín representa la sustitución de un solo dígito {0-9}.
  • Los comodines no pueden representar cambios que afecten a la seguridad

 

Esta formalización permite a los proveedores gestionar versiones menores sin presentar cambios al PCI SSC, siempre que el uso de comodines se valide durante la Evaluación Completa.

 

 

 

 

Requisitos de evaluación: El código fuente es obligatorio

La versión 2.0 hace explícito lo que antes estaba implícito:la disposición del código fuente de es obligatoria. La Guía del programa lo establece de forma inequívoca:

"Se espera que el proveedor de software proporcione el código fuente de su producto de software evaluado, si el evaluador que realiza la evaluación lo considera necesario. No es posible evaluar un producto de software conforme a esta norma sin proporcionar el código fuente pertinente".

Los requisitos de las pruebas se han reescrito completamente en torno a tres métodos:

  1. Revisión de la documentación
  2. Análisis estático
  3. Análisis dinámico

 

Ciclo de vida y procesos administrativos

El ciclo de vida de validación de 3 años permanece intacto:

  • Años 1 y 2: se requiere una declaración anual del proveedor
  • Año 3: Reevaluación necesaria para mantener la inclusión en la lista

 

Principales aclaraciones de la versión 2.0:

  • Periodo de caducidad administrativa: 45 días naturales tras el vencimiento del plazo de certificación, indicado en naranja en los listados.
  • Caducidad del listado: Tras el periodo de gracia de 45 días, los productos pasan a ser productos de software seguro caducados.
  • Losproductos caducados requieren una nueva evaluación, no una reevaluación, para volver a figurar en la lista.

 

Notificación de problemas de seguridad: Nueva sección específica

La versión 2.0 introduce una sección dedicada Sección 8 para la notificación de problemas de seguridad, formalizando:

  • los plazos de notificación exigidos por la VRA
  • Formato de notificación requerido (escrito, precedido de correo electrónico)
  • Detalles mínimos de la notificación, incluida la puntuación CVSS
  • Acciones de respuesta del PCI SSC, incluida la posible retirada de la aceptación.

 

Implicaciones prácticas para las partes interesadas

Para proveedores de software

  • Revise sus productos con respecto a la nueva definición de activo sensible.
  • Actualice las metodologías de versionado para aprovechar las ventajas de los comodines.
  • Prepare listas de materiales completas para su evaluación
  • Considerar la cualificación SSLC para los beneficios de Cambio Delta de Nivel 1
  • Garantizar la disponibilidad del código fuente para las evaluaciones

 

Para empresas evaluadoras de SSF

  • Completar la formación requerida v2.x antes de realizar las evaluaciones
  • Familiarizarse con el nuevo documento SAID
  • Actualice las metodologías de evaluación para la nueva estructura de requisitos de prueba.
  • Prepárese para las evaluaciones SDK del Módulo D

 

Para los clientes

  • Compruebe que los proveedores proporcionan directrices de implementación coherentes con los números de versión indicados.
  • Comprender que las dependencias obligatorias forman parte de la validación: el uso de dependencias no incluidas en la lista invalida el listado.
  • Supervise las fechas de certificación de los proveedores y los plazos de reevaluación.

 

Conclusión

PCI Secure Software Standard v2.0 representa una maduración del marco, pasando de categorías de software de pago prescriptivas a un enfoque basado en principios centrado en la protección de activos sensibles. La inclusión de funciones de evaluación de SDK, la formalización de versiones comodín y el sistema de cambios delta por niveles apuntan a un programa de validación más flexible y sostenible.

Para las organizaciones que actualmente cuentan con validaciones v1.x o están planificando nuevas evaluaciones, ahora es el momento de ponerse en contacto con empresas evaluadoras de SSF cualificadas para comprender la ruta de transición y aprovechar la mayor flexibilidad que ofrece esta importante revisión.

La norma PCI Secure Software Standard v2.0 y la Guía del Programa v2.0 entran en vigor en enero de 2026. Las organizaciones deben consultar la documentación oficial del PCI SSC y a los evaluadores cualificados para obtener orientación específica sobre el cumplimiento.