Guía para fundadores sobre el checklist de cumplimiento PCI DSS

Todo fundador fintech se hace la misma pregunta tarde o temprano: ¿de verdad tenemos que preocuparnos por PCI DSS, o eso ya lo resuelve Stripe por nosotros? La respuesta honesta queda en un punto intermedio. Si tu app toca datos de tarjeta en algún punto, incluso a través de una pasarela validada por PCI, PCI DSS te aplica a ti, y dejarlo para cuando un banco socio lo pida es la razón por la que tantas startups corren contrarreloj semanas antes del lanzamiento. Esta guía repasa un checklist de cumplimiento PCI DSS práctico: a quién le aplica, qué significan los 12 requisitos, cómo funcionan los tipos de SAQ y qué cambió en PCI DSS 4.0. Nada de esto sustituye a un Qualified Security Assessor para una validación formal, pero te va a llevar más lejos que la página de marketing de un proveedor.

PCI DSS son las siglas de Payment Card Industry Data Security Standard: un conjunto de requisitos creados para proteger los datos de tarjeta, mantenidos por el PCI Security Standards Council (fundado por Visa, Mastercard, American Express, Discover y JCB en 2006). Esto sorprende a la mayoría de los fundadores: PCI DSS es una obligación contractual, no una ley, y queda escrita en los acuerdos que firmas con tu banco, tu procesador o tu pasarela de pago. Si lo incumples, las consecuencias son multas de las marcas de tarjeta, tarifas de procesamiento más altas o, en el peor de los casos, perder la posibilidad de aceptar tarjetas. El estándar aplica a tu entorno de datos del titular de la tarjeta, o CDE: las personas, procesos y tecnología que almacenan, procesan o transmiten datos de tarjeta, más todo lo que esté lo bastante conectado a ese entorno como para afectar su seguridad.

PCI DSS aplica a cualquier organización que almacene, procese o transmita datos de tarjeta, o que pueda afectar la seguridad de un entorno de datos del titular de la tarjeta. Es una red deliberadamente amplia: comercios, procesadores, pasarelas y proveedores de software cuyo producto toque datos de tarjeta en cualquier punto quedan bajo su alcance. El tamaño no te exime: una startup de dos personas que procesa sus primeras cien transacciones a través de Stripe ya entra en el alcance en cuanto un número de tarjeta real pasa por su sistema. Lo que cambia con el tamaño y el volumen es cómo demuestras el cumplimiento, y de eso hablamos a continuación. Si ya estás definiendo los requisitos de KYC y AML para un MVP fintech, PCI DSS es la vía paralela para los datos de tarjeta, y ambos temas suelen salir en la misma conversación con un socio bancario o dentro de una planificación más amplia de desarrollo de software fintech.

Las redes de tarjetas clasifican a los comercios en cuatro niveles de cumplimiento, sobre todo según el volumen anual de transacciones (los umbrales varían un poco según la marca de tarjeta): el Nivel 1 es más de seis millones de transacciones al año o cualquier comercio que haya sufrido una brecha, el Nivel 2 va de uno a seis millones, el Nivel 3 de veinte mil a un millón de transacciones de e-commerce, y el Nivel 4 es todo lo que queda por debajo. Casi todas las startups arrancan en el Nivel 4. Lo que tienes que hacer para demostrar cumplimiento depende de tu nivel. Los comercios de Nivel 1 suelen necesitar una evaluación anual presencial de un Qualified Security Assessor (QSA). El resto normalmente se autoevalúa con un Self-Assessment Questionnaire, o SAQ: preguntas de sí o no mapeadas a los requisitos que correspondan a tu configuración. Qué SAQ te toca completar depende de cómo te llegan los datos de tarjeta, no de tu sector ni del tamaño de tu equipo. También existen algunos tipos más específicos (B, B-IP, C, P2PE); la tabla de abajo cubre lo que se encuentra la mayoría de las startups.

Si quitas el lenguaje legal, el checklist de cumplimiento PCI DSS se reduce a doce requisitos agrupados en seis objetivos. No vas a implementar los doce tú mismo: buena parte recae en tu pasarela, tu proveedor de nube o tu socio BaaS. Aun así, conviene saber qué pide cada uno. Eso de 'nuestro proveedor se encarga de eso' solo es cierto hasta que alguien te pide que lo demuestres.

La palanca más rápida para reducir el alcance PCI: que los datos de tarjeta sin procesar nunca toquen tus propios servidores. Los hosted fields (un iframe o una redirección que controla la pasarela) y la tokenización hacen justo eso. El número de tarjeta del cliente va directo a la pasarela; tu backend solo ve un token, inútil para quien lo robe. Bien implementado, esto te baja del cuestionario más pesado, SAQ D, al más corto, SAQ A. Explicamos cómo funciona esto, tokenización incluida, en nuestra guía de integración de pasarelas de pago. Reducir el alcance tiene límites. La segmentación de red sigue importando incluso con un checkout alojado; una red mal segmentada puede meter de vuelta en el alcance a sistemas que no tienen nada que ver. Externalizar el checkout no externaliza todo: una herramienta de reembolsos o una hoja de cálculo con un número de tarjeta pegado puede anular el beneficio en silencio.

PCI DSS 3.2.1 se retiró en marzo de 2024. Si un proveedor o una entrada de blog vieja todavía habla de la 3.2.1, es señal de que el consejo está desactualizado. La versión vigente es la 4.0.1, una revisión de aclaración sobre la 4.0, y ahora todos los requisitos son obligatorios, incluidos los que al principio eran solo 'buenas prácticas' (ese periodo de gracia terminó el 31 de marzo de 2025). Hay unos cuantos cambios que le importan más a una startup que el resto. La autenticación multifactor ahora aplica a todo acceso al entorno de datos del titular de la tarjeta, mucho más allá del acceso remoto o de administrador, y el mínimo de la contraseña pasó de siete a doce caracteres. ¿Manejas un checkout de e-commerce? Los nuevos requisitos sobre gestión de scripts del lado del cliente y manipulación de la página de pago, pensados para ataques de skimming en JavaScript, merecen una revisión aunque uses una pasarela alojada. El estándar también introdujo un 'enfoque personalizado' para cumplir los requisitos de otra manera, respaldado por un análisis de riesgo documentado. Flexible sobre el papel; a la mayoría de las startups todavía les va mejor con el enfoque definido estándar en la etapa MVP.

Hay un puñado de errores que se repiten una y otra vez cuando definimos el alcance del stack de pagos de un MVP fintech. Almacenar el CVV después de la autorización encabeza la lista, casi siempre dentro de una herramienta de soporte pensada para agilizar reembolsos. Guardar el CVV después de la autorización no está permitido nunca, cifrado o no. Los números de tarjeta pegados en logs, en el rastreador de errores o en una hoja de cálculo compartida quedan cerca en segundo lugar, casi nunca a propósito: un stack trace captura el cuerpo bruto de una solicitud, o alguien del equipo pega un número en un chat para resolver un cobro fallido. Asumir que una pasarela validada por PCI te vuelve compliant por asociación es otro error habitual. Reduce el alcance de forma notable, un beneficio real, pero de todas formas tienes que completar el SAQ que corresponda y firmarlo. Luego está la expansión de alcance silenciosa: un CDE que arranca limpio y, meses después, comparte red con la mitad de las herramientas de la empresa porque nadie trazó un límite. Para las prácticas de seguridad más amplias detrás de todo esto, revisa nuestra guía de seguridad y escalabilidad para MVP.

No todos los requisitos merecen la misma atención el primer día. Si estás definiendo el alcance de pagos para un MVP fintech, aquí tienes, a grandes rasgos, dónde conviene invertir primero tu tiempo limitado:

• Enruta todos los datos de tarjeta a través de hosted fields o una redirección desde el primer día. Rehacer esto después de que tu propio código ya tocó números sin procesar cuesta mucho más que construirlo bien desde el principio.
• Confirma qué SAQ te corresponde antes de que tu socio bancario lo pregunte.
• Fija ya un estándar de MFA y contraseñas para toda la organización, incluso con tres personas en el equipo. Sale barato hacerlo temprano y caro añadirlo después.
• Mantén los datos de tarjeta fuera de logs, herramientas de soporte y hojas de cálculo como regla estricta desde la primera línea de código de pagos.
• Documenta el límite de tu CDE, aunque sea con un solo diagrama.
• Revisa el alcance cada vez que una función toque los pagos de forma distinta: las suscripciones, los payouts o los reembolsos manuales lo amplían todos en silencio.
• Empieza a construir una relación con un QSA antes de necesitarlo, sobre todo si el crecimiento te puede empujar hacia el Nivel 1.

Si aciertas con los tres primeros puntos, el resto se vuelve notablemente más fácil.