Casi todas las conversaciones sobre PCI DSS que tenemos con responsables de tiendas online empiezan igual: un correo del banco adquirente o de la pasarela de pago avisando de que hay que «acreditar el cumplimiento PCI» antes de una fecha concreta. Hasta ese momento, la norma era algo abstracto que alguien mencionó en una reunión. A partir de ese correo, se convierte en un cuestionario de doscientas preguntas, un escaneo trimestral que falla y una discusión interna sobre quién es el responsable de todo esto.
La buena noticia es que la mayor parte del trabajo real de PCI DSS en un ecommerce no consiste en rellenar papeles, sino en tomar tres o cuatro decisiones de arquitectura que determinan cuánto te va a costar el cumplimiento durante los próximos años. Una tienda que ha externalizado bien el pago responde a un cuestionario de unas treinta preguntas. La misma tienda, con un formulario de tarjeta propio mal planteado, se enfrenta a un cuestionario de más de trescientas y a un coste anual que se multiplica por diez. La diferencia no está en el esfuerzo documental: está en por dónde pasa el número de tarjeta.
La otra noticia relevante es que la versión 4.0 de la norma dejó de ser opcional. Los requisitos que durante un tiempo figuraron como «buenas prácticas» con fecha diferida son ya exigibles, y dos de ellos —el 6.4.3 y el 11.6.1, que obligan a controlar los scripts que se ejecutan en la página de pago— afectan de lleno a cómo está construida una tienda moderna. Son, con diferencia, los que más equipos pillan desprevenidos, porque no se resuelven firmando un documento: hay que tocar código y montar monitorización.
En esta guía repasamos qué obliga PCI DSS a una tienda online española en 2026, cómo se determina el nivel de comerciante y el cuestionario que te corresponde, qué decisiones de arquitectura reducen el alcance de forma drástica, qué significa cada uno de los doce requisitos traducido a tareas concretas de un equipo de desarrollo, y cómo abordar un plan de cumplimiento en noventa días sin paralizar el roadmap del negocio.
1. Qué es PCI DSS y a quién obliga realmente
PCI DSS (Payment Card Industry Data Security Standard) es el estándar de seguridad que mantiene el PCI Security Standards Council, un organismo creado por las marcas de tarjeta —Visa, Mastercard, American Express, Discover y JCB— para unificar los requisitos de protección de los datos de tarjeta. No es una ley europea ni española: es una obligación contractual. Cuando tu empresa firma con un banco adquirente o con una pasarela de pago, en la letra pequeña de ese contrato aparece el compromiso de cumplir PCI DSS.
Esa naturaleza contractual tiene dos consecuencias prácticas que conviene entender bien. La primera es que nadie de la administración va a inspeccionarte: quien te reclama el cumplimiento es tu proveedor de pagos, y su herramienta de presión es directa —puede aplicar recargos por transacción, retener fondos o, en el extremo, cortar tu capacidad de cobrar con tarjeta. La segunda es que, ante un incidente con datos de tarjeta comprometidos, el incumplimiento acreditado cambia por completo el reparto de responsabilidad económica: multas de las marcas, coste de la investigación forense obligatoria, reemisión de tarjetas afectadas y, con frecuencia, pérdida de la cobertura del seguro.
Conviene además separar PCI DSS del RGPD, porque se confunden a menudo. El RGPD protege datos personales y su autoridad es la AEPD; PCI DSS protege un dato muy concreto —el PAN o número de tarjeta, junto con la fecha de caducidad, el nombre del titular y los datos de autenticación— y su autoridad son las marcas de tarjeta. Se solapan, porque un número de tarjeta también es un dato personal, pero cumplir uno no implica cumplir el otro. Lo mismo ocurre con las certificaciones de gestión: tener un SGSI conforme a ISO 27001 te da una base excelente de políticas y controles, pero PCI DSS es mucho más prescriptivo en el detalle técnico. Si vienes de ese mundo, buena parte del trabajo de los controles técnicos de ISO 27001 sobre acceso, cifrado y desarrollo seguro te sirve como punto de partida, pero no sustituye al cuestionario.
1.1 Qué datos entran en el alcance
La norma distingue entre datos del titular (número de tarjeta, nombre, fecha de caducidad y código de servicio) y datos sensibles de autenticación (la banda magnética completa, el CVV/CVC y el PIN). Los primeros pueden almacenarse si se protegen adecuadamente; los segundos no pueden almacenarse nunca después de la autorización, ni siquiera cifrados. Es un matiz que sigue causando incidentes: es sorprendentemente habitual encontrar el CVV en un log de depuración, en el payload guardado de una llamada a la pasarela o en el correo de confirmación que el sistema envía a atención al cliente.
El alcance —el «CDE» o entorno de datos de tarjeta— incluye todo sistema que almacene, procese o transmita esos datos, y también todo sistema que pueda afectar a la seguridad de los anteriores. Esa segunda parte es la que se olvida: un servidor de logs que recibe trazas del checkout, un backup, una herramienta de soporte que muestra pedidos completos o el ordenador desde el que un administrador entra al backoffice pueden entrar en alcance sin que nadie lo haya decidido conscientemente.
2. Niveles de comerciante: qué te toca demostrar
PCI DSS clasifica a los comercios en cuatro niveles según el volumen anual de transacciones con tarjeta. Los umbrales los fija cada marca y varían ligeramente entre ellas, pero el esquema de Visa y Mastercard es el de referencia en Europa.
El Nivel 1 agrupa a quienes superan los seis millones de transacciones anuales con una marca, y también a cualquier comercio que haya sufrido una brecha de datos de tarjeta, independientemente de su volumen. Exige una auditoría anual in situ realizada por un QSA (Qualified Security Assessor) externo, que emite un informe formal llamado ROC (Report on Compliance). El Nivel 2 cubre entre uno y seis millones de transacciones y suele resolverse con un cuestionario de autoevaluación, aunque algunos adquirentes exigen que lo valide un QSA o un ISA interno certificado. El Nivel 3 corresponde a tiendas online entre veinte mil y un millón de transacciones, y el Nivel 4 al resto: autoevaluación y escaneo trimestral de vulnerabilidades por un ASV (Approved Scanning Vendor) autorizado.
La inmensa mayoría de tiendas online españolas están en niveles 3 y 4, lo que significa que su obligación se materializa en tres entregables: un SAQ (Self-Assessment Questionnaire) firmado, un certificado de escaneo ASV trimestral con resultado aprobado y un AOC (Attestation of Compliance) que se entrega al adquirente. Suena manejable, y lo es —siempre que el SAQ que te corresponda sea el corto.
3. SAQ A, A-EP y D: la decisión que lo cambia todo
El cuestionario que te corresponde no lo eliges tú: lo determina la arquitectura de tu checkout. Y la diferencia entre uno y otro es la variable que más impacto tiene en el coste total del cumplimiento, muy por encima de cualquier otra decisión que tomes después.
3.1 SAQ A: pago completamente externalizado
Es el escenario más cómodo. Tu tienda redirige al cliente al dominio de la pasarela —Redsys, Stripe Checkout, PayPal— o embebe un iframe servido íntegramente por ella. El formulario donde se teclea la tarjeta pertenece al proveedor, se sirve desde su dominio y tu código no interviene en absoluto en la captura ni en la transmisión del PAN.
El cuestionario ronda las treinta preguntas y se centra en aspectos que puedes controlar sin esfuerzo desproporcionado: que no guardes datos de tarjeta en ningún sitio, que gestiones bien los accesos al backoffice, que tengas contratos y evidencias de cumplimiento de tus proveedores, y que apliques políticas básicas. En muchos casos ni siquiera se exige escaneo ASV, porque tus sistemas quedan fuera del entorno de datos de tarjeta.
3.2 SAQ A-EP: el que casi nadie espera
Aquí es donde caen muchas tiendas sin saberlo. Si usas los campos embebidos de la pasarela —Stripe Elements, Adyen Components, los hosted fields de Redsys— el número de tarjeta viaja directamente del navegador al proveedor y nunca toca tu servidor. Eso suena a SAQ A, pero no lo es: tu página es la que carga el JavaScript que renderiza esos campos, y por tanto tu código puede afectar a la seguridad de la transacción. Si alguien inyecta un script malicioso en tu página de pago, puede leer lo que el cliente teclea aunque el dato nunca pase por tu backend.
El cuestionario salta a unas ciento noventa preguntas y exige escaneo ASV trimestral, gestión de parches, control de cambios, desarrollo seguro y registro de eventos. Es un salto enorme respecto al SAQ A y explica por qué, cuando el equipo de desarrollo propone «mejorar la experiencia del checkout integrando los campos en nuestra propia página», conviene poner el coste de cumplimiento encima de la mesa antes de decidir. A veces compensa; a veces la mejora de conversión no paga el sobrecoste regulatorio. Nosotros lo hemos visto caer de los dos lados, y por eso recomendamos medirlo: si estás trabajando la conversión del embudo de pago, merece la pena cruzar estos números con lo que cuentan los datos reales de fricción, pagos y confianza en el checkout.
3.3 SAQ D: el PAN pasa por tus sistemas
Si tu tienda tiene un formulario propio que envía la tarjeta a tu servidor y desde ahí a la pasarela, si tu atención al cliente toma pedidos por teléfono apuntando el número, o si almacenas tarjetas para pagos recurrentes sin tokenizar, estás en SAQ D. Más de trescientas preguntas, segmentación de red, cifrado con gestión documentada de claves, pentest anual, revisión diaria de logs y controles físicos.
Para una pyme, SAQ D es casi siempre una señal de que hay que rediseñar el flujo de pago, no de que haya que ponerse a rellenar el cuestionario. El coste anual de mantener ese nivel —herramientas, auditoría, tiempo de equipo— supera con holgura el de una refactorización del checkout que devuelva la tienda a SAQ A o A-EP. Si estás montando pagos recurrentes, la tokenización del proveedor resuelve el problema de raíz y evita entrar en este territorio.
4. Qué cambia con PCI DSS 4.0.1
La versión 4.0 del estándar se publicó en 2022 y la revisión 4.0.1 —correcciones y aclaraciones, sin requisitos nuevos— en 2024. La versión 3.2.1 quedó retirada en marzo de 2024, así que cualquier evaluación actual se hace contra la 4.x. Y, sobre todo, el periodo de gracia terminó: los requisitos que figuraban como «buenas prácticas hasta el 31 de marzo de 2025» son hoy plenamente exigibles.
Los cambios más relevantes para un ecommerce son cuatro. El primero es la autenticación multifactor generalizada: ya no basta con exigir MFA para el acceso remoto administrativo, sino para todo acceso al entorno de datos de tarjeta, incluido el de los usuarios internos. El segundo es el endurecimiento de la política de contraseñas, que pasa a un mínimo de doce caracteres y obliga a comprobar las credenciales contra listas de contraseñas comprometidas. El tercero es la exigencia de análisis de riesgo documentado para justificar la frecuencia de determinados controles cuando se opta por el enfoque personalizado. Y el cuarto, el que más trabajo genera, es el control de los scripts en la página de pago.
4.1 El enfoque personalizado
La versión 4.0 introdujo una alternativa al cumplimiento literal: el customized approach. Permite a una organización madura demostrar que alcanza el objetivo de seguridad de un requisito por un medio distinto al prescrito, siempre que documente el análisis de riesgo y lo valide un QSA. Es una puerta útil para entornos complejos, pero no es un atajo para pymes: exige más documentación y más criterio técnico que cumplir el requisito tal cual está escrito.
5. Requisitos 6.4.3 y 11.6.1: los scripts de la página de pago
Si tienes que quedarte con una sola sección de este artículo, que sea esta. Los requisitos 6.4.3 y 11.6.1 son la respuesta del estándar a los ataques de tipo Magecart, también llamados web skimming: el atacante no entra en tu servidor ni roba tu base de datos, simplemente consigue que en la página de pago se ejecute un script que lee lo que el cliente teclea y lo envía a un servidor controlado por él. El cliente paga con normalidad, el pedido se procesa, nadie nota nada durante meses.
La vía de entrada habitual no es tu código, sino la cadena de suministro: una etiqueta de analítica, un chat de soporte, un píxel publicitario, un plugin de reseñas, una librería cargada desde un CDN de terceros. Todos ellos ejecutan JavaScript con los mismos privilegios que tu propio código dentro de la página. Si el proveedor es comprometido, tú heredas el problema. Es el mismo razonamiento que aplicamos al revisar dependencias en cualquier proyecto, y encaja con lo que ya explicamos sobre las vulnerabilidades del OWASP Top 10 y cómo prevenirlas.
5.1 Qué exige exactamente 6.4.3
El requisito obliga a gestionar todos los scripts que se cargan y ejecutan en la página de pago del navegador del cliente. En la práctica significa tres cosas: mantener un inventario de scripts autorizados con justificación escrita de por qué cada uno es necesario, disponer de un método que garantice la integridad de cada script, y contar con un proceso de autorización previa antes de que cualquier script nuevo llegue a producción.
Técnicamente se resuelve con una combinación de medidas. La integridad se cubre con Subresource Integrity: el atributo integrity en la etiqueta script con el hash del fichero, de modo que el navegador se niega a ejecutarlo si ha cambiado un solo byte. Para los scripts que cambian con frecuencia y no admiten SRI, la alternativa es una Content-Security-Policy restrictiva con lista de orígenes permitidos y directiva report-uri para recoger las violaciones. El inventario, una hoja o un fichero versionado en el repositorio que se revisa en cada release, es la parte aburrida pero imprescindible: sin él no hay evidencia que presentar.
5.2 Qué exige 11.6.1
El 11.6.1 es el complemento del anterior: obliga a desplegar un mecanismo que detecte cambios no autorizados en las cabeceras HTTP y en el contenido de la página de pago, y que genere una alerta. La frecuencia mínima es semanal, salvo que un análisis de riesgo documentado justifique otra distinta.
Las opciones van desde soluciones comerciales de monitorización client-side hasta un script propio que recorra periódicamente la página de pago con un navegador headless, calcule el hash del DOM relevante y de las cabeceras de seguridad, y compare con la referencia aprobada. Para una tienda mediana, un job programado que ejecute esa comprobación y avise por correo o por el canal de incidencias del equipo cumple perfectamente, siempre que se documente el diseño y se conserven las evidencias de ejecución. Lo importante es que exista, que alguien lea las alertas y que quede registro.
¿No sabes qué SAQ te toca ni si tu checkout cumple el 6.4.3?
En Keliam revisamos la arquitectura real de tu tienda, determinamos el alcance PCI DSS que te corresponde y te damos un plan concreto para reducirlo: inventario de scripts, cabeceras, tokenización y monitorización de la página de pago.
6. Arquitectura que reduce el alcance
Antes de rellenar un solo cuestionario, la pregunta correcta es: ¿cómo hago que mis sistemas queden fuera del entorno de datos de tarjeta? Cada sistema que sacas del alcance es un sistema que no tienes que endurecer, escanear, registrar ni auditar durante los próximos años.
6.1 Tokenización: no guardar lo que no necesitas
La regla de oro es que el dato más seguro es el que no tienes. Todas las pasarelas modernas ofrecen tokenización: en lugar del número de tarjeta, tu sistema guarda un identificador opaco que solo sirve para pedirle a esa pasarela que cobre de nuevo. Con eso resuelves suscripciones, pagos recurrentes, one-click y devoluciones sin almacenar un solo PAN.
Si tu tienda guarda tarjetas en base de datos «porque el cliente lo pide», el trabajo no es cifrarlas mejor: es migrar a tokens y purgar el histórico, incluidos los backups y los entornos de preproducción con copia de producción, que es donde suelen quedarse olvidados.
6.2 Segmentación de red
Si por el motivo que sea parte de tu infraestructura queda en alcance, segmentarla evita que el resto entre con ella. Una VLAN o una red virtual separada para el entorno de pago, con reglas de firewall explícitas y tráfico documentado, reduce el número de sistemas que hay que evaluar. La segmentación debe validarse: no vale con dibujarla, hay que probar que efectivamente no hay conectividad desde el resto de la red. Aquí las técnicas habituales de pentesting aplicado a tiendas online son exactamente la evidencia que pide el auditor.
6.3 Higiene de logs y trazas
Un porcentaje sorprendente de hallazgos en auditorías reales no viene del checkout, sino de los logs. Integraciones que vuelcan el payload completo de la llamada a la pasarela, sistemas de monitorización de errores que capturan el contenido de los formularios, herramientas de grabación de sesión que registran lo que el usuario teclea. Antes de dar por bueno cualquier diseño, conviene revisar qué acaba escrito en disco, y eso incluye las integraciones por API con ERP, logística y pasarelas de pago que muchas veces nadie ha vuelto a mirar desde que se pusieron en marcha.
7. Los doce requisitos traducidos a trabajo de equipo
El estándar se organiza en doce requisitos agrupados en seis objetivos de control. Leídos en el PDF original resultan áridos; traducidos a tareas concretas se entienden mucho mejor.
Requisitos 1 y 2 — red y configuración. Firewall con reglas documentadas, revisión periódica del ruleset y eliminación de credenciales y servicios por defecto. En una tienda alojada en cloud, esto son grupos de seguridad bien definidos y plantillas de hardening reproducibles, no un documento en Word.
Requisitos 3 y 4 — protección del dato. No almacenar datos sensibles de autenticación, enmascarar el PAN allí donde se muestre, cifrar lo que se guarde con gestión documentada de claves, y usar TLS 1.2 como mínimo en cualquier transmisión por redes públicas. HSTS, certificados renovados automáticamente y ninguna excepción para «entornos internos».
Requisito 5 — antimalware. Protección en los sistemas que lo admitan, con definiciones actualizadas y registro de la actividad. En servidores Linux se cubre con integridad de ficheros y detección de cambios más que con un antivirus tradicional.
Requisito 6 — desarrollo seguro y parches. Es el requisito más denso para un equipo técnico: ventanas de parcheo con plazos definidos según criticidad, revisión de código, formación en desarrollo seguro, protección frente a las vulnerabilidades web habituales y, desde la 4.0, el ya comentado 6.4.3 sobre scripts de la página de pago. Si en tu empresa nadie ha mirado nunca el código con criterio de seguridad, una auditoría de código profesional es la forma más eficiente de saber por dónde empezar.
Requisitos 7 y 8 — acceso e identidad. Permisos por necesidad de conocer, roles definidos, cuentas nominales sin usuarios compartidos, MFA para todo acceso al entorno y revisión periódica de altas y bajas. El backoffice de la tienda entra aquí de lleno: cada usuario con rol de administrador que ya no trabaja en la empresa es un hallazgo.
Requisito 9 — seguridad física. Menos relevante si todo está en cloud, pero no desaparece: control de acceso a oficinas donde se manejan pedidos, destrucción segura de documentación en papel y control de dispositivos de captura si hay TPV físico.
Requisitos 10 y 11 — monitorización y pruebas. Logs centralizados con sincronización horaria, retención de al menos un año con tres meses accesibles de inmediato, revisión de eventos, escaneos ASV trimestrales, escaneos internos, pentest anual en los niveles que lo exigen y el 11.6.1 de detección de cambios en la página de pago.
Requisito 12 — política y gobernanza. Política de seguridad aprobada y revisada anualmente, responsables identificados, formación del personal, gestión de proveedores con evidencias de su propio cumplimiento y un plan de respuesta a incidentes probado. Este último no es papel mojado: ante una brecha con datos de tarjeta, hay plazos contractuales de notificación al adquirente que se cuentan en horas.
8. Errores habituales por plataforma
Los patrones se repiten según la tecnología de la tienda, y conocerlos ahorra semanas de diagnóstico.
8.1 WooCommerce
El riesgo principal es el ecosistema de plugins. Cada extensión activa en el checkout carga su propio JavaScript, y muchas lo hacen desde dominios de terceros sin control de integridad: es la vía directa al incumplimiento del 6.4.3. Se suma el problema clásico de los plugins abandonados y sin actualizar, y el de las pasarelas que guardan el payload completo de la respuesta en la tabla de pedidos «por si acaso». La base de un checkout conforme en WooCommerce es reducir al mínimo lo que se ejecuta en esa página concreta y mantener una disciplina de actualizaciones seria, la misma que describimos en la guía de seguridad de WordPress para empresas.
8.2 PrestaShop
Las instalaciones antiguas arrastran módulos de pago propios que capturan la tarjeta en el servidor —SAQ D sin que nadie lo haya decidido— y overrides del core que complican cualquier actualización. El otro punto recurrente son los accesos al back office: cuentas de empleados antiguos, perfiles con permisos excesivos y ausencia de MFA.
8.3 Magento y Adobe Commerce
Fueron el objetivo histórico de Magecart. Aquí lo crítico es la disciplina de parches de seguridad, la revisión del contenido inyectable desde el CMS —bloques y widgets que permiten meter scripts arbitrarios en páginas del checkout— y el control de los procesos de integración que mueven datos hacia el ERP.
8.4 Shopify y SaaS
La plataforma cubre buena parte del alcance, pero no todo. Las apps instaladas siguen inyectando scripts en el storefront y, en planes que permiten personalizar el checkout, la responsabilidad sobre lo que se ejecuta ahí vuelve a ser tuya. Conviene revisar qué apps tienen permisos sobre datos de pedido y cuáles cargan recursos externos.
9. Plan de 90 días para llegar a cumplir
Un plan realista para una tienda de nivel 3 o 4 que parte de cero se organiza en tres bloques de un mes.
9.1 Mes 1: saber dónde estás
Dibujar el flujo completo del dato de tarjeta desde que el cliente lo teclea hasta que se confirma el cobro, identificando cada sistema que lo toca o que puede influir en él. Determinar con el adquirente tu nivel y el SAQ que te corresponde. Inventariar todos los scripts que se cargan en la página de pago —la consola del navegador y la pestaña de red son suficientes para empezar— y buscar activamente datos de tarjeta donde no deberían estar: logs, tablas, backups, exportaciones a Excel y buzones de atención al cliente.
9.2 Mes 2: reducir alcance y cerrar lo técnico
Migrar a tokenización lo que siga almacenando PAN, eliminar campos y trazas innecesarias, activar MFA en todos los accesos administrativos, revisar y recortar usuarios y roles, implantar SRI y una CSP en la página de pago, centralizar logs y contratar el escaneo ASV para tener el primer informe trimestral en marcha. Si arrastras una tienda antigua que nadie ha revisado a fondo, este es el momento de plantear una auditoría de seguridad específica de ecommerce en lugar de ir tapando hallazgos uno a uno.
9.3 Mes 3: documentar, monitorizar y firmar
Desplegar la detección de cambios del 11.6.1, redactar la política de seguridad y el plan de respuesta a incidentes, recopilar los AOC de tus proveedores, formar al equipo y, con todo lo anterior hecho, rellenar el SAQ y emitir el AOC para el adquirente. Rellenar el cuestionario es lo último, no lo primero: hacerlo al revés lleva a firmar declaraciones que no se sostienen.
10. Costes reales y qué esperar
Para una tienda de nivel 4 con SAQ A, el coste recurrente es bajo: poco más que el tiempo interno de revisar el cuestionario una vez al año y mantener la higiene de accesos. En SAQ A-EP entran el escaneo ASV trimestral, el tiempo de remediar sus hallazgos y las herramientas de monitorización de scripts, con un coste anual que en una pyme suele moverse en el entorno de unos pocos miles de euros más las horas de equipo. SAQ D multiplica esa cifra y añade pentest anual y, con frecuencia, apoyo externo de un QSA.
El error de cálculo más caro no está en esas cifras, sino en tratar el cumplimiento como un proyecto puntual. PCI DSS es continuo: los escaneos son trimestrales, los accesos se revisan periódicamente, el inventario de scripts cambia cada vez que marketing añade una etiqueta. Sin un responsable asignado y un calendario, el cumplimiento se degrada en pocos meses y el siguiente cuestionario vuelve a costar lo mismo que el primero. Y si lo que te preocupa es el escenario en el que algo sale mal, conviene tener presente cómo se desarrolla un incidente real de extremo a extremo: lo contamos en el artículo sobre cómo funciona el ransomware y cómo protegerse, donde el patrón de respuesta y plazos es muy parecido.
Conclusión
PCI DSS no es un trámite administrativo ni una certificación que se cuelga en la web: es un conjunto de decisiones técnicas con consecuencias económicas directas. La más importante se toma al diseñar el checkout, porque determina si tu obligación anual serán treinta preguntas o trescientas. La segunda más importante llega con la versión 4.x y afecta a algo que hasta hace poco nadie vigilaba: los scripts de terceros que se ejecutan en la página donde el cliente teclea su tarjeta.
Si tu tienda funciona con redirección o iframe de la pasarela, tienes mucho ganado y el trabajo se concentra en higiene de accesos, control de proveedores y no guardar lo que no debes. Si has integrado campos de pago en tu propio dominio, asume el alcance ampliado y organiza el escaneo trimestral, el inventario de scripts y la monitorización desde el principio. Y si en algún punto del flujo el número de tarjeta pasa por tus sistemas, la conversación correcta no es cómo rellenar el SAQ D, sino cómo rediseñar el flujo para no tener que hacerlo.
El punto de partida siempre es el mismo: dibujar el recorrido del dato y mirar sin prejuicios dónde acaba. Casi todos los proyectos que hemos acompañado empezaron encontrando datos de tarjeta en un sitio donde nadie sabía que estaban.
Preguntas frecuentes sobre PCI DSS en ecommerce
¿Es obligatorio PCI DSS por ley en España?
No es una obligación legal, sino contractual con tu banco adquirente y las marcas de tarjeta. En la práctica, si aceptas pagos con tarjeta, estás obligado por contrato, y el incumplimiento puede traducirse en recargos, retención de fondos o pérdida del servicio.
Si uso Stripe o Redsys, ¿ya cumplo?
Tu proveedor cumple en su parte, pero eso no te exime. Sigues siendo responsable de tu web, de tus accesos, de los scripts que cargas en la página de pago y de no almacenar datos indebidamente. Lo que sí hace una buena integración es reducir enormemente tu alcance.
¿Cada cuánto hay que renovar el cumplimiento?
El SAQ y el AOC son anuales. Los escaneos ASV, cuando aplican, son trimestrales y deben salir aprobados. Además hay revisiones con otras frecuencias —accesos, logs, reglas de firewall— que deben documentarse.
¿Qué pasa si sufro una brecha y no cumplía?
Se activa una investigación forense a tu cargo, se te pueden imponer multas por parte de las marcas, se repercuten los costes de reemisión de tarjetas y el comercio pasa automáticamente a ser tratado como nivel 1 en futuras evaluaciones. Muchas pólizas de ciberriesgo excluyen además la cobertura si el incumplimiento estaba acreditado.
¿Puedo guardar el CVV si lo cifro?
No. Los datos sensibles de autenticación —CVV, banda magnética y PIN— no pueden almacenarse después de la autorización bajo ninguna circunstancia, ni siquiera cifrados. Es una de las prohibiciones absolutas del estándar.
