PCI Secure SLC 2.0: el software de pagos necesita un plan de transición

El 28 de septiembre de 2026, el PCI SSC publicó la versión 2.0 del Secure Software Lifecycle Standard. La actualización tiene en cuenta las herramientas digitales, incluida la AI. La capacitación de los evaluadores está prevista para el cuarto trimestre; la transición de doce meses desde la versión 1.1 comienza cuando esté disponible esa capacitación, y no automáticamente el día de la publicación del estándar.

Qué se evalúa exactamente

Secure SLC se refiere al ciclo de vida del desarrollo. Para quien compra software de pagos, es una distinción importante: el producto terminado y el proceso para crearlo son objetos de evaluación distintos. El PCI SSC aclara por separado que la evaluación según Secure SLC y la evaluación según Secure Software no dependen una de la otra. Por eso, una declaración general del proveedor sobre el cumplimiento de PCI, sin nombrar el estándar ni el alcance de la evaluación, no es suficientemente informativa.

Pensemos en una corrección urgente de una integración de pagos. El código puede ser breve, pero para publicarlo de forma segura importan el acceso del autor, la revisión del cambio, la compilación, la autorización del release y la posibilidad de revertirlo. Si uno de los pasos existe solo como un acuerdo informal en un chat, reconstruir la historia después de un incidente es más difícil. Es un ejemplo editorial de por qué el proceso de desarrollo tiene importancia propia.

Las herramientas de AI añaden otro tramo a esta historia. El equipo debe entender qué materiales se entregan a la herramienta y cómo su resultado llega al producto en producción. Que una persona haya pulsado el botón de publicación no explica por sí solo el origen ni la revisión del cambio. De ahí el valor práctico de una lista actualizada de herramientas y de una ruta documentada del código.

Para el proveedor, la tarea inmediata es contrastar su proceso actual con la nueva versión y confirmar el calendario del programa con el evaluador. Para el comercio, se trata de entender qué validación tiene el desarrollador y cómo la mantiene vigente. Esto no implica una nueva evaluación inmediata para cada tienda.

En esta noticia es especialmente importante respetar la condición del período de transición. Si la capacitación aún no está disponible, el plazo no puede sustituirse por una fecha cómoda tomada del comunicado de prensa. El calendario exacto y el ámbito de aplicación tienen más valor práctico que la mera aparición de la cifra 2.0 en el nombre.

Qué deben revisar los proveedores de software y los PSP

Para los desarrolladores de soluciones de pago y los PSP que crean sus propias páginas de pago, SDK o integraciones, la noticia es una ocasión para hacer una breve revisión del proceso antes de que empiece el período de transición.

• Si está actualizado el inventario de herramientas de desarrollo, incluidos los asistentes de AI, y si hay reglas sobre qué datos se les pueden entregar.
• Si cada cambio pasa por revisión de código y autorización de publicación, incluidas las correcciones urgentes.
• Si se registran la compilación, el origen de las dependencias y la versión del código publicado de modo que la historia pueda reconstruirse.
• Si están separados los accesos de los desarrolladores al entorno de producción y a los datos de los titulares de tarjetas.
• Si hay un responsable designado que siga el calendario de transición y los plazos de capacitación de los evaluadores.

Qué significa para los comercios

Al comercio le conviene preguntar a sus proveedores de software de pagos qué estándar y qué alcance cubre exactamente su validación, cuándo vence la validación vigente y cómo planea el proveedor la transición. Estas preguntas deberían incluirse en la revisión anual de proveedores y en el contrato, sobre todo si la integración influye en el alcance de los propios requisitos de PCI DSS. Una respuesta del tipo «cumplimos con PCI» sin nombrar el estándar ni el alcance debe considerarse incompleta, y conviene pedir el documento que la respalde.

Para los equipos de desarrollo internos es útil preparar con antelación un paquete de evidencias: la descripción del proceso de publicación, el registro de cambios y la lista de herramientas. Puede servir tanto para el evaluador como para responder a grandes clientes que solicitan pruebas de la seguridad del desarrollo.

Fuentes: PCI SSC Secure SLC 2.0 release; PCI Secure SLC programme overview