--- title: "Checklist de cumplimiento PCI DSS" slug: "pci-dss-compliance-checklist-startups" url: "https://mvp-development.io/es/blog/pci-dss-compliance-checklist-startups" type: post lang: es date: "2026-05-21" last_modified: "2026-05-21" version: "1.0" summary: "Checklist práctico de cumplimiento PCI DSS para startups fintech: a quién aplica, los 12 requisitos explicados, los tipos de SAQ y qué cambió con PCI DSS 4.0." author: "MVP Development" tags: ["checklist de cumplimiento pci dss", "a quién aplica pci dss", "qué es el cde en pci dss", "pci dss 4.0", "software de cumplimiento pci dss", "saq", "reducir el alcance pci"] use: training: allow rag: allow embedding: allow attribution: required --- # 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. ## Qué es PCI DSS 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. ## A quién le aplica PCI DSS 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](https://mvp-development.io/blog/kyc-aml-compliance-fintech-mvp) 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](https://mvp-development.io/fintech). ## Los niveles de cumplimiento y los tipos de SAQ 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. ### Los tipos de SAQ de un vistazo | Tipo de SAQ | Para quién es | Qué significa para ti | | --- | --- | --- | | SAQ A | Checkout totalmente externalizado y alojado; los datos de tarjeta nunca tocan tus servidores | El cuestionario más corto; la meta para la mayoría de las startups | | SAQ A-EP | Checkout parcialmente alojado, pero tu código todavía toca la página de pago | Más exigencias, además de protecciones contra manipulación | | SAQ C-VT | Transacciones introducidas a mano a través de un terminal virtual, sin almacenamiento | Habitual en reembolsos gestionados por teléfono | | SAQ D (Merchant) | No encaja en una categoría más específica, o almacena datos de tarjeta directamente | El cuestionario más largo; las 12 categorías completas | Una prueba rápida: si nunca has escrito el número de tarjeta de un cliente en ningún sitio que no sea el campo alojado de una pasarela, seguramente estás en terreno SAQ A. En el momento en que tu propio código toca o guarda un número de tarjeta sin procesar, tu alcance sube de categoría. Confirma qué SAQ te corresponde en vez de asumir que es el más sencillo. ## El checklist de cumplimiento PCI DSS (los 12 requisitos, simplificados) 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. ### Los 12 requisitos de PCI DSS, simplificados | # | Requisito | Qué significa en la práctica | | --- | --- | --- | | 1 | Instalar y mantener controles de seguridad de red | Firewalls o controles equivalentes entre los sistemas y las redes no confiables | | 2 | Aplicar configuraciones seguras | Sin contraseñas por defecto ni ajustes de fábrica sin cambiar | | 3 | Proteger los datos de cuenta almacenados | No guardes datos que no necesites; nunca almacenes el CVV después de la autorización | | 4 | Proteger los datos de tarjeta en tránsito | Cifrado fuerte para los datos de tarjeta que cruzan redes públicas | | 5 | Proteger contra malware | Herramientas antimalware en los sistemas que podrían verse afectados | | 6 | Desarrollar y mantener sistemas y software seguros | Parches, código seguro y control de cambios para el CDE | | 7 | Restringir el acceso según la necesidad de saber | Acceso limitado a lo que cada rol realmente necesita | | 8 | Identificar usuarios y autenticar el acceso | Inicios de sesión únicos y autenticación multifactor para entrar al CDE | | 9 | Restringir el acceso físico | Controles físicos alrededor del hardware que maneja datos de tarjeta | | 10 | Registrar y monitorear el acceso | Registros de auditoría del acceso a los datos de tarjeta, conservados y revisados | | 11 | Probar la seguridad con regularidad | Escaneos de vulnerabilidades y, cuando aplica, escaneos ASV trimestrales | | 12 | Respaldarlo con políticas organizacionales | Una política de seguridad documentada y una evaluación formal de riesgos | ## Cómo reducir el alcance PCI (tokenización, hosted fields) 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](https://mvp-development.io/blog/payment-gateway-integration-guide). 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. ## Qué cambió en PCI DSS 4.0 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. El software de cumplimiento no va a rellenar tu SAQ por ti, pero herramientas como Vanta, Drata y Secureframe sí recortan tiempo real en la recopilación de evidencia: revisiones de acceso y documentos de política que se rastrean solos en lugar de perseguirlos a mano. Algunas ya venden revisión de evidencia asistida por IA para detectar huecos más rápido, útil para el trabajo mecánico, pero no sustituye el criterio de un QSA. ## Errores frecuentes de las startups con PCI DSS 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](https://mvp-development.io/blog/mvp-security-scalability-guide). Un error que vemos seguido: un equipo asume que su SAQ solo hay que revisarlo una vez al año, en la renovación. En realidad es un documento vivo. Agregas una herramienta de reembolsos, cambias de pasarela o dejas que un contratista toque el CDE sin actualizar quién es responsable, y tu entorno ya se alejó de lo que declaraste. ## Prioridades PCI para la etapa 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. ## FAQ **¿PCI DSS aplica a una startup que todavía no ha procesado ni una transacción?** En la práctica, todavía no. Las obligaciones arrancan en cuanto datos reales del titular de la tarjeta empiezan a moverse por tus sistemas, incluso en una beta limitada. Aun así, a la mayoría de las startups les va mejor diseñar pensando en el cumplimiento antes de la primera transacción que rehacer después un checkout construido sin PCI DSS en mente. **¿Qué cuenta exactamente como parte del CDE si uso una pasarela alojada?** Un pipeline de CI/CD que despliega tu checkout, un panel de reembolsos o el portátil de un contratista usado para depurar un cobro fallido pueden entrar en el alcance, aunque ninguno sea un lugar donde vivan números de tarjeta. Todo lo que pueda afectar la seguridad de los sistemas que sí los tienen también cuenta. Una pasarela alojada reduce esa huella, pero no la borra. **Mi QSA mencionó requisitos de la 3.2.1 en un documento viejo. ¿Debería preocuparme?** Vale la pena revisarlo, sí. Esa versión se retiró en marzo de 2024, así que cualquier evaluación que todavía la mencione está desactualizada. Eso no significa automáticamente que el consejo esté mal: muchos controles centrales pasaron a la 4.0 con solo cambios menores de redacción. **¿Qué debería buscar realmente en un software de cumplimiento PCI DSS?** Descarta cualquier herramienta que prometa dejarte 'automáticamente compliant'. Ningún software hace eso. Lo que importa más es si se ajusta al SAQ específico que estás completando, y si distingue entre herramientas de seguridad generales y la acreditación Approved Scanning Vendor (ASV) que se necesita para los escaneos externos. Confundir las dos cosas les cuesta tiempo real a los equipos en su primer ciclo de evaluación. **¿Qué es un SAQ, en términos simples?** Un ejecutivo de tu empresa lo firma y lo envía a tu banco adquirente o procesador, quien sea que lo haya pedido. Esa firma es una declaración formal, así que trátala como cualquier documento que firmarías con validez legal. La autoevaluación deja de ser suficiente en cuanto alcanzas el volumen de Nivel 1, donde la reemplaza una auditoría liderada por un QSA. **¿Cuál es la forma más rápida de reducir el alcance PCI si ya estamos a mitad de construcción y ya tocamos datos de tarjeta sin procesar?** Cambia tu checkout a hosted fields o a una redirección antes que nada. Es una refactorización más grande a mitad de camino, pero sigue siendo más rápido que blindar un CDE autogestionado hasta el nivel SAQ D. Cada semana dedicada a manejar datos de tarjeta a medida es una semana que no dedicas al producto. **¿Necesito contratar a un QSA si solo voy a completar una autoevaluación?** No es obligatorio para la mayoría de los tipos de SAQ; solo los comercios de Nivel 1 necesitan una evaluación liderada por un QSA. Aun así, pagar unas horas de un QSA para que revise tu configuración antes de autodeclararte es dinero bien invertido, sobre todo en tu primer SAQ. **¿Qué pasa realmente si una startup sufre una brecha de datos y resulta que no cumplía con PCI?** Varía según la gravedad y cómo ocurrió la brecha, así que conviene tomar con escepticismo cualquier cifra concreta que encuentres en internet. Espera multas de las marcas de tarjeta canalizadas a través de tu banco, escaladas según el volumen y qué tan lejos estabas de cumplir, tarifas de procesamiento más altas y una posibilidad real de perder el privilegio de procesar tarjetas si el fallo fue grave o ya habías declarado en falso. El costo mayor suele ser menos visible: notificación de la brecha, investigación forense y horas de los fundadores dedicadas a las consecuencias en lugar de al producto. Prevenir sale considerablemente más barato.