Un proyecto de PCI DSS que se sale de tiempo casi nunca falla en los controles. Falla antes: en el alcance.
Cuando el Cardholder Data Environment (CDE) se traza mal, cada revisión arrastra sistemas que nunca debieron estar ahí: más controles, más evidencia, y una evaluación de un trimestre estirada a todo el año. El orden correcto es el inverso. Primero defines qué toca el dato. Luego reduces esa superficie. Hasta el final eliges controles.
Qué es el CDE y qué cae dentro
El CDE son las personas, procesos y tecnologías que almacenan, procesan o transmiten datos del titular de tarjeta (CHD) o datos sensibles de autenticación (SAD).
- CHD: el PAN (Primary Account Number) y, cuando viajan con él, nombre del titular, fecha de vencimiento y código de servicio.
- SAD: datos de banda o chip, CVV2/CVC2/CAV2/CID, PIN y bloques de PIN. Prohibido almacenarlos después de la autorización (PCI DSS v4.0, Req. 3.3.1).
El error más común es detenerse ahí. El alcance también incluye los sistemas conectados al CDE y los que pueden afectar su seguridad: el directorio que autentica a los operadores, el bastión, el pipeline de CI/CD que despliega al CDE, el colector de bitácoras, la consola de tu cuenta cloud.
Acción: dibuja el flujo del PAN de punta a punta (captura → autorización → conciliación → almacenamiento → borrado) y clasifica cada sistema en tres cubetas: CDE, conectado o con impacto en seguridad, y fuera. Si no cae limpio en la tercera, está dentro.
La segmentación es la palanca #1
La segmentación de red no es un requisito del estándar. Es el mecanismo que decide su tamaño: sin segmentación, toda tu red plana es CDE y cada requisito aplica a todo.
En una fintech nativa de nube eso significa cuenta dedicada, red propia con salida controlada, denegación por defecto y un plano de identidad que no se comparte con el resto del negocio. Y hay que probarla: el estándar exige validar la segmentación con pruebas de penetración periódicas (Req. 11.4.5), más frecuentes para proveedores de servicio (Req. 11.4.6). Un diagrama no es evidencia; el reporte de pentest sí.
Acción: si tu CDE comparte hoy cuenta cloud, red o directorio con el resto de la empresa, ese es el primer proyecto.
Nivel de comerciante: define cómo te validas, no qué cumples
Todos cumplen el mismo estándar. El nivel determina cómo lo demuestras.
Los niveles los define cada marca de pago (Visa, Mastercard, American Express, Discover, JCB), no el PCI SSC. El criterio es el volumen anual de transacciones con esa marca, agregado por canal. Los umbrales difieren entre marcas y se actualizan: consúltalos en el programa de cumplimiento de cada una.
Nivel superior → evaluación in situ por un QSA (o un ISA interno certificado) que produce un ROC (Report on Compliance) y su AOC (Attestation of Compliance). Niveles inferiores → autoevaluación con el SAQ que corresponda a tu captura, más su AOC. Una filtración de datos o la decisión de tu adquirente pueden subirte de nivel sin importar el volumen, y los escaneos externos por un ASV aplican a los sistemas expuestos en cualquier nivel (Req. 11.3.2).
Acción: pide por escrito a tu adquirente en qué nivel te tiene clasificado y con qué marcas. Esa respuesta define el resto del plan.
SAQ A · SAQ A-EP · SAQ D
La diferencia no es el tamaño de tu empresa. Es quién controla el punto donde el usuario teclea el PAN.
| SAQ | Cómo se captura el PAN | Qué implica |
|---|---|---|
| A | Delegada por completo: redirección o iframe servido por el proveedor. Tus sistemas no almacenan, procesan ni transmiten CHD. | El conjunto de requisitos más acotado, con criterios de elegibilidad estrictos que tú mismo declaras y firmas. |
| A-EP | El pago lo procesa un tercero, pero tu sitio controla la captura: campo propio con envío directo, o JavaScript tuyo que arma el formulario. | Muchos más requisitos: servidor web, desarrollo, gestión de vulnerabilidades, control de cambios. |
| D | El PAN entra a tu entorno: tu API lo recibe, tu backend lo reenvía, lo almacenas o lo captura tu call center. | Prácticamente todos los requisitos. Hay una variante SAQ D para proveedores de servicio. |
Hay otros formularios para tarjeta presente (B, B-IP, C, C-VT y P2PE). Y con v4.0 el estándar sumó controles contra el e-skimming: gestión de los scripts que carga el navegador (Req. 6.4.3) y detección de manipulación de la página de pago (Req. 11.6.1). Verifica cuáles aplican en la versión vigente de tu SAQ.
Acción: abre el DOM de tu página de pago. Si el campo del PAN vive en un iframe del proveedor, estás en territorio de SAQ A. Si vive en tu DOM, estás en A-EP o peor, aunque cobre un tercero.
Tokenización: sacar el PAN de tu entorno
La decisión que más reduce alcance no es un control: es dejar de tocar el PAN. La captura ocurre en el dominio del proveedor (campos hospedados o redirección) o bajo P2PE validado en presencial, y tus sistemas solo reciben un token con el que operan cobros recurrentes, reembolsos y conciliación.
Cuatro advertencias, porque tokenizar mal no reduce nada:
- Si tu entorno puede des-tokenizar, el vault y todo lo que puede invocarlo siguen dentro del CDE.
- Si el PAN pasa por tu backend "solo un instante" antes de reenviarlo, ese backend es CDE.
- Conciliación en archivo, respaldos, grabaciones del call center y capturas de soporte también contienen PAN.
- El tokenizador es un TPSP: necesitas su AOC vigente y la matriz de responsabilidades (Req. 12.8.5).
Acción: inventaría cada punto donde el PAN todavía entra a tu red y asígnale un destino: campos hospedados, P2PE o eliminar ese flujo por completo. Los Information Supplements del PCI SSC sobre tokenización y sobre scoping y segmentación son la referencia primaria. ↗
PCI DSS v4.0: el enfoque personalizado
La v4.0 abre dos rutas. El defined approach implementa el control tal como está redactado y el evaluador aplica los procedimientos de prueba del estándar. El customized approach cumple el objetivo del requisito (Customized Approach Objective) con un control distinto, diseñado por ti.
No es un atajo. El requisito debe tener objetivo de enfoque personalizado; varios no lo admiten y el estándar lo señala. Documentas un análisis de riesgo dirigido conforme al Req. 12.3.2 y una matriz de controles: qué implementas, cómo cumple el objetivo, cómo se prueba y cómo sostienes su eficacia. El QSA diseña procedimientos de prueba a la medida y los documenta en el ROC. No lo confundas con los controles compensatorios: esos exigen una restricción legítima y siguen su propio formato.
Sobre versiones: v4.0.1 es una revisión limitada de v4.0 y v3.2.1 ya está retirada. Antes de comprometer fechas con tu adquirente, confirma en el sitio del PCI SSC la versión vigente y el calendario aplicable.
Acción: reserva el enfoque personalizado para controles maduros y medibles, por ejemplo autenticación resistente a phishing frente a reglas de complejidad de contraseña. Para el resto, el defined approach cuesta menos evidencia.
Cuatro errores que alargan la evaluación
Retención de bitácoras insuficiente. Hay que conservar el histórico de bitácoras de auditoría al menos 12 meses, con los últimos 3 meses disponibles de inmediato para análisis (PCI DSS v4.0, Req. 10.5.1). Las retenciones por defecto de varios servicios administrados en nube son menores. Revisa la retención efectiva por fuente.
Llaves administradas por la misma identidad que cifra. Si un rol puede usar la llave y también modificar su política, rotarla o eliminarla, no hay separación de funciones. Y el cifrado a nivel de disco tiene un uso acotado para volver ilegible el PAN (Req. 3.5.1.2): "el volumen está cifrado" no cierra el requisito.
Ambientes de prueba con datos reales. PAN vivos en QA o en un respaldo para reproducir un bug. El estándar lo prohíbe salvo que ese ambiente esté dentro del CDE y cumpla todo lo aplicable (Req. 6.5.5). Un dataset sintético cuesta menos que auditar staging.
Terceros sin AOC. Procesador, gateway, tokenizador, hosting, SOC administrado, call center. Necesitas inventario de TPSP, monitoreo de su estatus y una matriz de quién cubre qué requisito (Req. 12.8.4 y 12.8.5). "Nuestro proveedor es PCI compliant" no es evidencia; su AOC vigente, con el alcance correcto, sí.
Acción: solicita esos AOC esta semana. La respuesta de terceros es el retraso más común en la recta final.
Ruta de 4 pasos
- Mapa del dato. Flujo del PAN y del SAD, inventario clasificado en CDE, conectado y fuera, y lista de TPSP con su AOC. Sin esto, cualquier estimación de esfuerzo es ficción.
- Reducción de alcance. Mueve la captura a campos hospedados o redirección, tokeniza, elimina el almacenamiento que no necesitas y aísla el CDE en su propia cuenta cloud y su propio plano de identidad. Vuelve a dibujar el mapa: lo que queda es tu alcance real.
- Vía de validación. Con el nivel confirmado por tu adquirente y el alcance ya reducido, define si vas a ROC con QSA o a SAQ, y a cuál. Este es el momento de decidirlo, no el primero.
- Cierre de brechas y evidencia. Gap assessment contra la versión vigente y remediación priorizada. Arranca por los requisitos con periodicidad (bitácoras, escaneos ASV, pruebas de segmentación): necesitan historia acumulada antes de la evaluación.
El orden importa. Cada semana que inviertas en sacar el PAN de tu entorno te ahorra controles que después no tendrás que implementar, operar ni evidenciar durante años. →