¿Necesitas PCI SSF o PCI DSS? Aquí está la diferencia

Dicho de forma sencilla: PCI SSF es para el software, y PCI DSS es para todo lo demás.

Si desarrollas o vendes software relacionado con pagos, PCI SSF te aplica. Si almacenas, procesas o simplemente tocas datos de titulares de tarjetas de cualquier forma (incluyendo tu sitio web, servidor o stack de alojamiento), estás ante el cumplimiento de PCI DSS.

Ambos marcos provienen del mismo consejo (PCI SSC), pero abordan problemas muy distintos dentro del ecosistema.

La mayoría de la gente solo escucha hablar de los requisitos de PCI DSS porque es el que afecta a comercios, empresas SaaS y prácticamente a cualquiera que gestione una página de pagos. ¿Pero PCI SSF? Ese es para las empresas que escriben el software de pago que impulsa esos sistemas.

Vamos a desglosarlo.

¿Qué es PCI SSF?

PCI SSF son las siglas de Payment Card Industry Software Security Framework. Es el reemplazo más moderno y flexible de PA-DSS, la versión anterior.

Mientras que PCI DSS se centra en proteger los datos, PCI SSF se enfoca en proteger el software que toca esos datos. Es decir, el código que ejecuta tu sistema de punto de venta, tu app de monedero móvil o tu módulo de pago en el navegador.

PCI SSF comprende en realidad dos estándares:

• Secure Software Standard: Se centra en la seguridad del propio software. ¿Está reforzado? ¿Protege los datos del titular de la tarjeta? ¿Tiene controles de acceso adecuados integrados?
• Secure Software Lifecycle (Secure SLC): Analiza cómo se desarrolla el software. ¿Es seguro tu SDLC (ciclo de vida del desarrollo de software)? ¿Parcheas las vulnerabilidades con rapidez? ¿La seguridad es una prioridad desde el principio?

En otras palabras: PCI SSF se preocupa por cómo se escribe, mantiene y actualiza tu software. Si tu base de código es un desastre, no esperes superar una evaluación SSF.

¿A quién va dirigido PCI SSF?

Hazte estas preguntas:

• ¿Vendes o distribuyes aplicaciones de pago?
• ¿Tu software gestiona pagos directamente (aunque nunca almacene datos del titular de la tarjeta)?
• ¿Quieres aparecer en la lista de software de pago validado del PCI SSC?

Si respondiste sí a alguna de estas preguntas, necesitas cumplir con PCI SSF.

¿Qué tipo de software está en el alcance?

Si desarrollas herramientas que se distribuyen y participan en el flujo de datos del titular de la tarjeta, probablemente estás en el alcance.

Esto es lo que suele estar incluido:

• Sistemas POS: Software instalado en terminales físicas de pago.
• Apps de pago móvil: Aplicaciones que aceptan pagos con tarjeta a través de una interfaz móvil.
• SDKs de checkout: Componentes o librerías de pago que los comercios integran en sus sitios o apps.
• Thin clients: Aplicaciones ligeras que gestionan el enrutamiento de transacciones o la entrada de datos del usuario, pero que dependen de APIs externas.
• Software para quioscos o terminales: Cualquier código que impulse sistemas de cara al público que acepten tarjetas.

Y esto es lo que normalmente no está incluido:

• Aplicaciones solo para uso interno: Herramientas desarrolladas y utilizadas dentro de tu propia organización, sin distribución externa.
• Sistemas de back-office: ERPs o herramientas de análisis que no intervienen en el flujo de pago.
• Páginas alojadas sin lógica embebida: Si tu software simplemente redirige o enmarca una página alojada que ya cumple con PCI, eso por sí solo podría no activar SSF.

Si tu software se vende, se comercializa bajo marca blanca o se distribuye, y admite pagos con tarjeta, SSF casi con toda seguridad te aplica.

Ejemplos de empresas que necesitan PCI SSF:

Aquí algunos ejemplos. Ten en cuenta que no tenemos ninguna afiliación con las empresas mencionadas a continuación:

1. Proveedores de sistemas POS

Ejemplo: Toast, Lightspeed, Square (stack de software de hardware).

• Crean software distribuido que se instala en dispositivos físicos en entornos de retail y hostelería.
• El software acepta pagos con tarjeta e interactúa directamente con los lectores de tarjetas.
• Generalmente se enmarca en el Secure Software Standard.

2. Desarrolladores de apps de pago móvil

Ejemplo: SumUp, Zettle (by PayPal), Revolut Business.

• Apps móviles que permiten a pequeñas empresas o particulares aceptar pagos con tarjeta.
• A menudo implican lectores de tarjetas por Bluetooth y gestionan la introducción de datos de la tarjeta a través del teléfono o la tableta.
• La seguridad del software en estas apps debe verificarse de extremo a extremo.

3. Proveedores de SDKs de checkout o librerías de pago

Ejemplo:

• Estas empresas ofrecen componentes integrables que los comercios utilizan para aceptar pagos.
• Aunque los datos de la tarjeta se tokenizan rápidamente, el SDK sigue gestionando lógica sensible.
• La validación demuestra que el SDK no crea nuevas superficies de ataque.

4. Plataformas de comercio con pagos integrados

Ejemplo: Shopify, BigCommerce, Ecwid.

• Plataformas que ofrecen módulos de checkout integrados que los comercios utilizan "de serie".
• El software subyacente que facilita ese checkout a menudo necesita validación SSF si se distribuye.

5. Empresas de software para quioscos y terminales

Ejemplo: Nayax, Ingenico, Verifone (para desarrollos de software personalizados)

• Se utilizan en máquinas expendedoras, quioscos de venta de entradas y terminales de autopago.
• El software debe cumplir con los requisitos de resistencia a manipulaciones, integridad de actualizaciones y comunicaciones seguras.
• Estos entornos suelen ser "desatendidos", lo que hace que SSF sea aún más relevante.

6. Soluciones de pasarela bajo marca blanca

Ejemplo: Payrix, BlueSnap, Corepay

• Ofrecen infraestructura de pago que otras plataformas integran o revenden.
• El componente de software distribuido (campos alojados, SDKs, plugins) a menudo necesita validación.
• También ayuda a los clientes empresariales a reducir su propio alcance PCI.

7. Herramientas de pago orientadas a la seguridad

Ejemplo: Very Good Security (VGS), Basis Theory, TokenEx

• Estas empresas gestionan datos sensibles en entornos tipo proxy o en vaults.
• Sus SDKs del lado del cliente o librerías para el navegador pueden requerir validación SSF según cómo fluyan los datos de la tarjeta.

¿Qué exige realmente PCI SSF?

Cumplir con PCI SSF no se trata solo de tener código limpio o buenas intenciones. El marco establece objetivos de seguridad claros que tu software debe cumplir, y se verifican mediante una evaluación formal.

Algunos requisitos clave:

• Sin almacenamiento de datos sensibles: El software nunca debe almacenar números de tarjeta completos, códigos CVV ni datos de banda magnética en texto plano.
• Criptografía correcta: Se requieren algoritmos aceptados por la industria con una gestión adecuada de claves.
• Integridad de las actualizaciones: Las actualizaciones de software deben autenticarse y firmarse para evitar manipulaciones.
• Configuración segura por defecto: Las contraseñas de administrador, los ajustes de configuración y las políticas de acceso deben entregarse en un estado reforzado.
• Protección contra manipulaciones: Tu app debe detectar y responder a intentos de alterar el comportamiento en tiempo de ejecución (p. ej., inyección, scraping de memoria).
• Control de acceso: Los roles y permisos deben estar claramente definidos, aplicados y registrados.
• Registro y trazabilidad: Los registros de auditoría deben estar disponibles, ser seguros y resistentes a modificaciones.
• SDLC documentado: Tu ciclo de desarrollo debe demostrar que la seguridad está integrada en todo el proceso, desde el diseño hasta la entrega.

En resumen: los evaluadores esperarán que demuestres que la seguridad no es una ocurrencia de última hora.

¿Cómo es el proceso de validación?

La validación PCI SSF es formal y estructurada. La realiza un Secure Software Assessor (SSA). ¡No es una autoevaluación! El resultado es que tu producto queda listado en el sitio web del PCI SSC.

Aquí tienes una visión general del proceso:

• Definición del alcance: Define qué productos o componentes se van a presentar. Deberás aclarar qué funcionalidades están en el alcance y cómo encajan en el flujo de pago.

• Análisis de brechas (opcional): Algunos proveedores comienzan con una pre-evaluación para identificar las principales brechas antes de iniciar el proceso formal. No es obligatorio, pero puede ahorrar tiempo más adelante.

• Evaluación formal: El evaluador revisa tu:

• Remediación (si es necesaria): Si se detectan problemas, los corriges, actualizas la documentación y presentas evidencia de los cambios.

• Envío al PCI SSC: Una vez que el evaluador está satisfecho, presenta un informe al PCI SSC para su revisión.

• Publicación en la lista: Si se aprueba, tu software se publica en la lista oficial de aplicaciones de pago validadas.

Los plazos varían, pero la mayoría de las evaluaciones tardan desde unas semanas hasta varios meses, dependiendo del alcance, la madurez de la base de código y la claridad de la documentación.

¿Qué es PCI DSS?

PCI DSS (Payment Card Industry Data Security Standard) es el que la mayoría probablemente ya conoce, y está dirigido a todas las demás empresas que realizan transacciones en su sitio.

En esencia, PCI DSS dice:

Si tocas datos del titular de la tarjeta, debes protegerlos, ..., y aquí tienes 12 formas de hacerlo.

Y si has leído nuestro análisis en profundidad de PCI DSS 4.0.1, sabrás que esas 12 formas no son exactamente elementos de "marcar una casilla". Hablamos de:

• Controles de seguridad de red
• Protección antimalware
• Gestión de vulnerabilidades
• Monitorización y registro
• Desarrollo seguro de software
• Inventario de scripts (hola, PCI 6.4.3 👋)
• Protección de cabeceras de pago (hola de nuevo, 11.6.1 👋)

Tanto si eres un comercio con SAQ A, un proveedor de servicios o un desarrollador de apps de Shopify que usa campos alojados, PCI DSS es el marco que aplica a tu entorno de procesamiento de tarjetas en producción.

Aquí tienes enlaces a información anterior que escribimos sobre PCI DSS, en el orden en que deberías leerla:

• Cómo cumplir con PCI 6.4.3 y 11.6.1
• La gran actualización de PCI DSS de enero de 2025
• El desglose completo de PCI DSS 4.0.1
• ¿Cómo ser una empresa SAQ A?
• El riesgo de proteger solo tus páginas de pago

Entonces, ¿cuál es la diferencia?

Veámoslo lado a lado:

¿Puede una empresa estar sujeta a ambos?

Absolutamente. Supongamos que desarrollas y vendes un plugin de checkout (PCI SSF), pero también usas ese plugin en tu propio sitio de eCommerce (PCI DSS). Ahora tienes que gestionar ambos: asegurar tu base de código y también asegurar tu infraestructura.

Incluso si no gestionas datos de tarjetas directamente (p. ej., comercios SAQ A que usan Stripe o competidores con campos alojados), sigues estando sujeto a PCI DSS, probablemente a los requisitos de la versión 4.0 como 6.4.3 y 11.6.1, que te hacen responsable de los scripts de terceros y de la integridad del DOM.