PCI DSS para comercios: qué necesitas si aceptas tarjetas

PCI DSS es el estándar de seguridad que tu banco adquirente te exige por contrato si aceptas tarjetas. No lo impone ninguna ley española, y desde el 31 de marzo de 2025 pide bastante más que antes.

Quien te lo reclama es tu adquirente, no un regulador. La consecuencia de no cumplir está escrita en el contrato que firmaste con él y no en el BOE, así que conviene leerlo antes que buscar la respuesta en un blog.

¿Te aplica si el cobro lo lleva la pasarela?

Sí. Si tu web forma parte del flujo de pago, entras en el alcance aunque no guardes ni un número de tarjeta. La pasarela se queda con el almacenamiento. No se queda con la responsabilidad de la página desde la que se paga.

El caso lo reconoce cualquiera que tenga una tienda online. El checkout carga el iframe de la pasarela y, junto a él, el píxel de analítica, el chat de soporte y el gestor de etiquetas que instaló la agencia hace dos años. Ninguno de ellos toca tu servidor. Todos se ejecutan en la misma página en la que el cliente teclea los dieciséis dígitos.

Esa misma pasarela te traslada además la autenticación reforzada que exige PSD2, que es otra norma y otro trabajo. Conviene no mezclarlas.

Quién decide tu nivel, y no eres tú

El nivel de comerciante lo fija cada marca de tarjeta y te lo confirma tu adquirente. Visa lo dice con estas palabras: el volumen total de transacciones en doce meses determina el nivel y los requisitos de validación que te tocan.

Los umbrales concretos los publica cada marca por separado y no coinciden entre ellas, así que un mismo comercio puede caer en un nivel con una y en otro con la siguiente. No los deduzcas de la tabla de un blog, y esto incluye a este. Pide a tu adquirente por escrito en qué nivel te tiene clasificado y qué cuestionario espera recibir. Son dos líneas de correo y te ahorran preparar durante un mes el SAQ equivocado.

Lo que cambió el 31 de marzo de 2025

La versión 4.0 del estándar trajo 64 requisitos nuevos, y 51 de ellos fueron buenas prácticas hasta el 31 de marzo de 2025. Desde esa fecha son obligatorios, según el propio PCI Security Standards Council.

Los dos que más cambian la vida de una tienda online son el 6.4.3 y el 11.6.1, y los dos hablan de lo mismo: los scripts que se cargan en la página de pago. El motivo que da el Consejo es directo. Los scripts que corren en el navegador del cliente se han convertido en objetivo para robar los datos de la tarjeta, sin tocar el servidor de nadie.

• › Un inventario de cada script que se ejecuta en la página de pago, con quién lo puso y para qué.
• › Autorización expresa de cada uno, la del chat de soporte incluida.
• › Comprobación de integridad, para enterarte si el fichero que sirve un tercero cambia por su cuenta.
• › Detección de cambios no autorizados en la página de pago y en las cabeceras que la acompañan.

El SAQ A ya no es el atajo que era

Externalizar el pago sigue reduciendo el alcance, pero el SAQ A ya no se firma solo. Desde la entrada en vigor de la versión 4.0.1, el 1 de abril de 2025, el cuestionario incluye un criterio de elegibilidad nuevo: el comercio tiene que haber confirmado que su sitio no es susceptible a ataques mediante scripts que puedan afectar a sus sistemas de comercio electrónico.

La diferencia práctica es grande. Antes bastaba con declarar que el pago iba dentro de un iframe ajeno. Ahora hay que poder sostener esa frase, y el Consejo señala las técnicas de los requisitos 6.4.3 y 11.6.1 como la forma de llegar a ella. El criterio afecta a quien incrusta la página de pago en la suya; quien redirige al sitio del proveedor o externaliza el cobro por completo está en otro supuesto.

Es la creencia que más veces nos encontramos en la primera llamada: «lo lleva la pasarela, así que a mí no me aplica». Dejó de ser cierta en cuanto el pago se incrusta en tu página.

Qué pruebas técnicas exige PCI DSS, y cuáles no se sustituyen

El estándar pide cuatro comprobaciones distintas y ninguna sustituye a otra: escaneo externo trimestral por un proveedor ASV aprobado, escaneo interno trimestral, prueba de intrusión anual interna y externa, y prueba de la segmentación si la usas para recortar el alcance.

La confusión más repetida es dar el escaneo trimestral del ASV por cumplido el requisito 11.4. Son cosas distintas. Un escáner compara versiones contra una base de vulnerabilidades conocidas; una prueba de intrusión encadena dos fallos que por separado no dan nada y comprueba hasta dónde se llega desde ahí.

Los números de terceros apuntan en la misma dirección. La edición de 2026 del Data Breach Investigations Report de Verizon sitúa las vulnerabilidades de software como el origen del 31 % de las brechas, por delante ya de las contraseñas robadas. La periodicidad razonable más allá del mínimo anual la desarrollamos en cada cuánto hacer un pentest.

El error que multiplica la factura: definir mal el alcance

Todo sistema que almacena, procesa o transmite datos de tarjeta entra en el alcance, y también todo el que esté conectado a esos sin una segmentación efectiva. Una red plana convierte la empresa entera en entorno de datos de tarjeta.

La diferencia se ve en la factura. Auditar doce servidores y auditar cuatrocientos no cuesta lo mismo, y el salto no lo provoca el negocio. Lo provoca una VLAN que alguien abrió para que la impresora de administración llegase al servidor de pedidos, y que nadie volvió a cerrar.

Por eso la segmentación se prueba y no se declara. Si dices que el entorno de pago está aislado, el evaluador pide la evidencia de que ese aislamiento aguanta cuando alguien empuja. Esa evidencia sale de una auditoría de infraestructura interna, que parte de 1.520 €, y en Pentesting Team se documenta con el intento de salto y su resultado, se consiga o no.

¿Cuánto cuesta la prueba de intrusión que pide el estándar?

El pentesting de aplicaciones web sobre la aplicación de pago parte de 1.140 €, y la auditoría de la superficie externa, de 450 €. La auditoría lleva de una a tres semanas según el número de flujos y de roles, y el informe técnico, de uno a tres días más.

Lo que se entrega son dos informes y una sesión. El técnico trae cada vulnerabilidad con su criticidad, su evidencia y los pasos para reproducirla, que es lo que debe incluir un informe de pentesting para que sirva ante un tercero. El ejecutivo es el que enseñas a quien responde ante el adquirente. La presentación dura media hora y te quedas con las diapositivas. Tienes hasta seis meses para pedir el retest, que se cierra con un informe nuevo.

La pregunta razonable antes de encargarlo es por qué no se lo pides a quien ya te administra los sistemas. Porque nadie audita bien lo que ha configurado. Su incentivo es que salga limpio y el nuestro es encontrar lo que falla, y por eso en Pentesting Team el plan de auditoría va por escrito antes de empezar, con las pruebas previstas, las fechas y el equipo.

Por dónde empezar el lunes

Pide a tu adquirente por escrito el nivel en el que te tiene clasificado y el cuestionario que espera recibir. Con esa respuesta delante, lo primero es el inventario de los scripts de la página de pago: es lo que cambió en 2025 y es lo que casi nadie tiene hecho. La prueba de intrusión viene después, cuando ya sabes qué entra en el alcance y no pagas por auditar lo que sobra.