Diagrama de flujo de datos PCI DSS: mapear datos de titulares de tarjeta y reducir el alcance

Una evaluación PCI DSS suele empezar con la misma petición: muéstrennos adónde van los datos de tarjeta. El diagrama de tu wiki muestra servicios y flechas, pero no qué flechas llevan un número de tarjeta, cuáles solo un token ni por qué el almacén de analítica está fuera de alcance. Sin eso, cada sistema se convierte en una discusión de alcance.

Este artículo cubre qué pide PCI DSS v4.0.1, las categorías de alcance, un checkout resuelto con campos de pago alojados, tokens, segmentación, tipos de SAQ y mantenimiento. No es asesoría legal ni de cumplimiento: tu adquirente o tu evaluador decide qué aplica, y los textos oficiales están en la PCI SSC Document Library.

Qué pide PCI DSS v4.0.1

PCI DSS v4.0.1, publicada en junio de 2024, es la versión vigente al momento de escribir (noviembre de 2026). Sus requisitos con fecha futura pasaron a ser obligatorios el 31 de marzo de 2025. Tres requisitos dan forma a tus diagramas:

Los datos de cuenta incluyen los datos del titular de la tarjeta (PAN, nombre del titular, fecha de vencimiento, código de servicio) y los datos de autenticación confidenciales (datos completos de banda magnética, código de verificación de la tarjeta, PIN y bloques de PIN). El PAN es el elemento definitorio: si lo almacenas, procesas o transmites, tienes un entorno de datos del titular de la tarjeta (CDE).

SAQ A no contiene ni el requisito 1 ni el 12.5.2, SAQ A-EP incluye 1.2.3 y 1.2.4, y SAQ D y las evaluaciones completas incluyen los tres. Incluso con SAQ A, el diagrama sigue siendo tu evidencia más clara de elegibilidad.

Tres tipos de sistemas

La sección 4 aplica los requisitos al CDE y a todo lo que «pudiera afectar la seguridad de los datos del titular de la tarjeta y/o de los datos de autenticación confidenciales», una redacción que la v4.0.1 introdujo en lugar de «la seguridad del CDE». El ejemplo del propio estándar es «un servidor web que controla la generación de un formulario o una página de pago». La guía de alcance del PCI SSC clasifica los sistemas en tres categorías, que se comprueban de arriba abajo:

Un sistema pertenece a la categoría más alta que cumple. La segmentación es opcional, pero sin ella toda la «red plana» está en alcance, y el cifrado por sí solo normalmente no saca los datos de tarjeta del alcance.

El ejemplo: un checkout con campos de pago alojados

Una aplicación web de tienda sirve la página de pago; sus campos de tarjeta son un iframe del proveedor de pagos, a menudo llamados campos alojados (hosted fields). Un servicio de pedidos cobra los pagos, Postgres almacena los pedidos, un trabajo nocturno alimenta un almacén y CI/CD despliega la tienda:

1. El navegador carga la página de pago; el script del proveedor renderiza los campos de tarjeta en su propio iframe.
2. El cliente escribe el PAN, la fecha de vencimiento y el CVC, y el navegador los envía por TLS directo al proveedor. La política del mismo origen mantiene los scripts de la página del comercio fuera del iframe.
3. El proveedor almacena el PAN en su vault y devuelve un token.
4. La página envía el pedido y el token al servicio de pedidos.
5. El servicio de pedidos cobra el token a través de la API del proveedor con una clave secreta, y el proveedor solicita la autorización a través de la red de tarjetas.
6. Un webhook confirma el resultado. El servicio de pedidos almacena el ID del token, la marca de la tarjeta y los últimos cuatro dígitos.

Ningún sistema del comercio almacena, procesa ni transmite el PAN, así que el comercio no tiene CDE; tú gestionas al proveedor, que tiene su propia evaluación, según el requisito 12.8. El diagrama de integración de pasarela de pago muestra el mismo checkout como secuencia, y el diagrama de la plataforma de e-commerce lo sitúa entre los servicios de catálogo, carrito y pedidos.

La aplicación web sigue en alcance: un atacante que la modifique, o modifique un script que carga, puede cambiar el iframe por un formulario falso. Ese ataque, el e-skimming, es la razón por la que la v4.0 añadió 6.4.3 (autorizar, comprobar la integridad e inventariar los scripts de las páginas de pago) y 11.6.1 (detectar cambios en las páginas de pago). CI/CD también está en alcance, ya que el estándar cuenta las herramientas de despliegue como componentes del sistema.

Tokens y qué dejan en alcance

Las directrices de tokenización del PCI SSC colocan el sistema de tokenización, incluida la destokenización y el almacenamiento del PAN, en el CDE. Los sistemas que solo guardan tokens pueden quedar fuera de alcance si el PAN no se puede recuperar a partir de los tokens, no pueden solicitar la destokenización ni llegar al vault, y están segmentados del CDE.

El proveedor es dueño del vault, así que el servicio de pedidos y la base de datos pueden calificar, con una salvedad: un token reutilizable más la clave secreta de la API puede crear cobros. La guía dice que los tokens que pueden iniciar una transacción «podrían estar en alcance de PCI DSS» y recomienda a los comercios consultar a su adquirente. Protege la clave como cualquier secreto de producción.

Segmentación y cómo se prueba

La segmentación suele significar reglas de firewall, grupos de seguridad o cuentas de nube separadas. Si aísla un CDE, el requisito 11.4.5 exige pruebas de penetración de esos controles al menos cada 12 meses y tras los cambios (cada seis meses para proveedores de servicios), realizadas por un evaluador calificado e independiente. En el diagrama de red de 1.2.3, dibuja cada segmento y los controles entre ellos, como en una topología de red lógica.

Sin CDE del comercio, el límite que importa rodea todo lo que puede modificar la página de pago: el servicio de pedidos, el almacén y sus credenciales no deben poder desplegar en la tienda.

Decisiones de arquitectura y tipos de SAQ

El diseño de tu checkout decide en buena parte el cuestionario de autoevaluación (SAQ); tu adquirente lo confirma:

La revisión de enero de 2025 de SAQ A eliminó 6.4.3 y 11.6.1 del cuestionario y añadió un criterio de elegibilidad: el comercio confirma que «su sitio no es susceptible a ataques de scripts que podrían afectar a los sistemas de comercio electrónico del comercio». La FAQ 1588 permite dos vías: proteger tu página con técnicas como las de 6.4.3 y 11.6.1, u obtener la confirmación de tu proveedor de que su solución lo hace, cuando se implementa según las instrucciones. El criterio se aplica a los iframes incrustados, no a las redirecciones, y ambos siguen necesitando análisis trimestrales de un Approved Scanning Vendor (FAQ 1604). Un solo campo de tarjeta renderizado por tu propia página descarta SAQ A.

Mantener el diagrama al día

El estándar considera «cualquier cambio en el flujo o el almacenamiento de datos de cuenta» como potencialmente significativo. Actualiza el diagrama cada vez que añadas un método de pago, un proveedor o un canal, un script del checkout, o una exportación, un pipeline de logs o una herramienta de soporte que toque datos de pago.

Vigila los números de tarjeta en tickets de soporte y chats: para un canal no intencionado así, la v4.0.1 dice que se debe incorporar al CDE o eliminar los datos de forma segura e impedir que el canal se use para ello. Pon la fecha, el autor y el aprobador en el diagrama; el flujo de documentación viva trata de responsables y desencadenantes de actualización.

El diagrama de flujo de datos del titular de la tarjeta

Cómo leerlo:

• Tres zonas. El rojo es el CDE del proveedor, el ámbar agrupa los sistemas del comercio que pueden modificar la página de pago, y el turquesa agrupa los sistemas que solo manejan tokens.
• Los colores siguen a los datos: rojo para datos de tarjeta, turquesa para tokens, gris para ninguno; las líneas discontinuas indican asíncrono.
• Los números siguen una compra. El camino rojo nunca entra en un marco del comercio.
• Dos notas marcan los riesgos restantes: los scripts de la página y los tokens reutilizables.
• La leyenda resume las clases de datos y el alcance.

Dibujar con claridad diagramas de flujo de datos PCI DSS

Etiqueta cada flujo y cada almacén:

• Dibuja el alcance como marcos y sombrea las áreas fuera de alcance, como sugiere la guía de 1.2.3.
• Dibuja un diagrama por canal: comercio electrónico, teléfono y terminales son distintos.
• Incluye los caminos silenciosos: reembolsos, contracargos, copias de seguridad, logs y herramientas de soporte.
• Haz que coincida con el diagrama de red, que el diagrama de flujo de datos debe complementar.
• Deja fuera las llamadas sin datos de cuenta ni tokens.

Un error común es una línea de PAN que atraviesa sistemas que solo manejan tokens, lo que los mete en el alcance sobre el papel. Consulta los ejemplos de diagramas de flujo de datos para la notación, la guía de modelado de amenazas para los límites de confianza y el mapa de datos GDPR para un inventario similar.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Añade una Persona del paquete Modelo C4 para el navegador del cliente.
3. Añade tres nodos Marco del paquete Básico para el proveedor (rojo), el comercio en alcance (ámbar) y el comercio fuera de alcance (turquesa).
4. En el marco del proveedor, añade dos nodos Sistema externo del paquete Modelo C4 para los campos alojados y la API de pagos, y una Bóveda del paquete Seguridad. Coloca un Sistema externo para las redes de tarjetas debajo del marco.
5. En el marco ámbar, añade un Contenedor del paquete Modelo C4 para la aplicación web y una Canalización del paquete DevOps.
6. En el marco turquesa, añade un Contenedor para el servicio de pedidos y nodos Postgres y Almacén de datos del paquete Datos.
7. Dibuja aristas etiquetadas: rojo para datos de tarjeta, turquesa para tokens, gris en los demás casos, discontinuas para el webhook y la exportación.
8. Añade una leyenda Markdown del paquete Básico y dos notas Texto del paquete Básico.

Para el diagrama de red de 1.2.3, el conversor de Terraform te da un primer borrador a partir de tus archivos .tf; la página de diagrama de flujo de pagos muestra vistas de secuencia.

El ejemplo usa 14 nodos de diagrama, dentro del plan Free.

Preguntas frecuentes

¿PCI DSS exige un diagrama de flujo de datos? Sí. El requisito 1.2.4 de la v4.0.1 pide un diagrama de flujo de datos exacto de todos los flujos de datos de cuenta, mantenido al día. SAQ A lo omite; SAQ A-EP, SAQ D y las evaluaciones completas lo incluyen.

¿Cuál es la diferencia entre el diagrama de red PCI y el diagrama de flujo de datos? El diagrama de red (1.2.3) muestra las conexiones entre el CDE y otras redes. El diagrama de flujo de datos (1.2.4) muestra adónde viajan y dónde se almacenan los datos de cuenta. Deben coincidir.

¿Un iframe o una página de pago alojada saca mi sitio web del alcance de PCI? No. Mantiene los datos de tarjeta fuera de tus sistemas, pero la página que incrusta el iframe aún puede ser atacada, por eso SAQ A pide análisis ASV trimestrales y, para iframes, protección contra ataques de scripts.

¿Los sistemas que solo almacenan tokens quedan fuera del alcance de PCI DSS? Pueden quedar fuera, si el PAN no se puede recuperar a partir de los tokens y los sistemas están segmentados del sistema de tokenización. Los tokens que pueden iniciar una transacción aún pueden estar en alcance.

¿Con qué frecuencia deben revisarse el alcance PCI y los diagramas? Actualiza el diagrama de flujo de datos cada vez que cambien los flujos de datos de cuenta, y confirma el alcance al menos cada 12 meses y tras cambios significativos (12.5.2), o cada seis meses para proveedores de servicios.

Empieza gratis — un puesto, sin tarjeta de crédito.