Resumen rápido
- PCI DSS es un estándar internacional de seguridad para los datos de tarjetas, no una ley española.
- Afecta a comercios y otras entidades que almacenan, procesan o transmiten datos de tarjeta, y también puede alcanzar sistemas capaces de afectar a la seguridad del entorno de pago.
- Utilizar un proveedor externo puede reducir considerablemente el alcance, pero no te permite desentenderte por completo de PCI DSS.
- No todos los negocios tienen que demostrar el cumplimiento de la misma forma. Puede intervenir un SAQ, un AOC, escaneos ASV o evaluaciones más amplias según el caso.
- Un datáfono físico, un checkout alojado y un formulario que captura tarjetas directamente en tu web no generan el mismo nivel de exposición.
- La mejor estrategia para un pequeño comercio suele ser clara: minimizar los datos que toca, elegir bien a sus proveedores, mantener sus sistemas seguros y confirmar con su adquirente qué validación le corresponde.
¿Qué es PCI DSS y qué protege realmente?
PCI DSS son las siglas de Payment Card Industry Data Security Standard. Es el estándar de seguridad desarrollado para establecer requisitos técnicos y operativos que ayuden a proteger los datos asociados a los pagos con tarjeta.
El propio PCI Security Standards Council indica que el estándar está pensado para entidades que almacenan, procesan o transmiten datos del titular de la tarjeta o datos de autenticación sensibles, así como para aquellas que pueden afectar a la seguridad del entorno donde se manejan esos datos. Esto incluye comercios, procesadores, adquirentes y proveedores de servicios.
Puedes consultar directamente el estándar PCI DSS del PCI Security Standards Council. La biblioteca oficial identifica PCI DSS v4.0.1 como la versión de referencia.
En lenguaje normal, PCI DSS intenta evitar que información sensible quede expuesta porque una tienda, web, servidor, terminal o proveedor está mal configurado o tiene controles de seguridad insuficientes.
Entre los datos relevantes están el número principal de la tarjeta —PAN— y determinada información asociada. También existen datos de autenticación especialmente sensibles, como el código de verificación o determinados datos utilizados para autenticar la operación.
La pregunta que debería hacerse un comercio no es solo “¿guardo números de tarjeta?”, sino algo más amplio:
¿En qué momento mis sistemas pueden ver, recibir, transmitir o influir en la seguridad de esos datos?
Esa diferencia cambia por completo el alcance de PCI DSS.
¿PCI DSS es obligatorio para un comercio en España?
PCI DSS no es una ley española ni un reglamento europeo. Es un estándar global de la industria de pagos. Eso no significa que sea opcional para un negocio que acepta tarjetas.
Las marcas de pago y los adquirentes gestionan sus propios programas de cumplimiento y determinan cómo debe demostrarse ese cumplimiento. PCI SSC explica que son normalmente estas entidades las que deciden si un comercio debe presentar, por ejemplo, un cuestionario de autoevaluación o un informe más amplio.
Puedes revisar la explicación oficial sobre cómo se determina la validación del cumplimiento PCI DSS.
Aquí conviene distinguir dos conceptos que se mezclan mucho:
Cumplir PCI DSS significa que los controles que corresponden a tu entorno están correctamente implantados.
Validar el cumplimiento significa demostrarlo mediante el procedimiento que corresponda: cuestionarios, declaraciones, informes, escaneos u otras evidencias.
No deberías escoger por tu cuenta un formulario porque “parece el de los comercios pequeños”. El tipo de validación depende de cómo aceptas los pagos, de tu infraestructura y de las reglas que aplique la entidad a la que tendrás que presentar la documentación.
¿Y si todos los pagos los gestiona otra empresa?
Tampoco puedes asumir que desaparece PCI DSS.
El PCI Security Standards Council explica expresamente que, aunque un comercio externalice todo el procesamiento y no almacene, procese ni transmita directamente datos del titular, sigue teniendo responsabilidades respecto al proveedor que utiliza y a la protección de esos datos.
Entre otras cuestiones, debe saber qué proveedor presta realmente el servicio, comprobar que su cumplimiento cubre los servicios utilizados y entender qué responsabilidades conserva cada parte.
Este es probablemente el error más habitual:
“Mi pasarela cumple PCI DSS, así que yo ya no tengo que preocuparme de nada.”
No es una buena forma de plantearlo. Es más correcto decir que un proveedor adecuado puede asumir gran parte del trabajo y reducir mucho tu exposición.
Cómo cambia PCI DSS según la forma en la que cobras
La forma más útil de entender PCI DSS es dejar de pensar por un momento en formularios y mirar el recorrido que sigue un pago.
No tiene la misma exposición una cafetería que únicamente utiliza un terminal gestionado por un proveedor que una tienda online cuyo propio servidor recibe los números de tarjeta.
| Forma de cobro | Dónde se introducen los datos | Exposición habitual del comercio | Qué merece especial atención |
|---|---|---|---|
| Datáfono físico gestionado | En el terminal | Normalmente menor | Terminal, accesos, manipulación y proveedor |
| Checkout alojado externo | En la página del proveedor | Menor | Web, redirección, proveedor y validación |
| Formulario externo integrado | Dentro de la experiencia de la web | Variable | Integración, scripts y seguridad de la web |
| Captura mediante sistemas propios | Infraestructura del comercio | Mayor | Servidores, redes, aplicaciones y accesos |
| Cobro telefónico o manual | Personal y sistemas internos | Variable | Procedimientos, almacenamiento y acceso |
Esta tabla sirve para entender el riesgo, no para decidir automáticamente qué SAQ corresponde a cada negocio.
Si cobras con un datáfono físico
Imagina una cafetería que cobra todas sus ventas mediante un terminal suministrado y gestionado por su proveedor. El personal introduce el importe, el cliente paga y la cafetería nunca copia el número de la tarjeta a su ordenador, software de caja o documentos internos.
Su entorno puede ser bastante más sencillo que el de un negocio que maneja datos de tarjeta directamente.
Eso no significa que pueda olvidarse de la seguridad. Sigue siendo importante revisar el terminal, controlar quién puede utilizarlo, evitar dispositivos manipulados y saber quién presta el servicio.
Si quieres entender mejor qué ocurre detrás de una operación presencial, puedes revisar cómo funciona un datáfono.
En sectores donde se realizan muchos cobros presenciales, como bares y restaurantes, también importa cómo se conecta el terminal con el resto de la operativa. Nuestra comparativa de TPV para hostelería ayuda a distinguir la parte de gestión del negocio de la parte estrictamente relacionada con el procesamiento del pago.
Si cobras mediante un TPV virtual o checkout alojado
En comercio electrónico la arquitectura importa muchísimo.
Un modelo relativamente sencillo es el checkout alojado: el cliente inicia la compra en tu web, pero los datos de su tarjeta se introducen directamente en un entorno gestionado por el proveedor de pagos.
Esto puede reducir considerablemente el alcance porque tus propios sistemas no necesitan recibir directamente esa información.
Si estás montando una tienda online, merece la pena entender primero cómo funciona un TPV virtual.
En plataformas concretas ocurre lo mismo. Una tienda puede utilizar una redirección completa, un checkout externo o una integración más profunda. En nuestra guía de TPV virtual para WooCommerce puedes ver cómo cambia la integración según la solución elegida.
Pero cuidado con una simplificación frecuente: que el formulario de pago esté externalizado no significa necesariamente que la web del comercio deje de importar.
PCI DSS contempla controles sobre determinadas webs que pueden influir en la seguridad de una transacción incluso cuando los datos de tarjeta se introducen en infraestructura de terceros. En algunos entornos ecommerce también pueden existir requisitos de escaneo externo mediante un ASV.
Si los datos pasan por tu propia integración
El escenario se complica cuando un comercio desarrolla un formulario o una infraestructura donde sus sistemas reciben directamente datos de la tarjeta.
Ahí entran más componentes en juego: servidores, código, usuarios, redes, registros, actualizaciones, controles de acceso y monitorización.
Dicho de otra forma: tener más control técnico sobre el pago suele implicar también asumir más responsabilidad técnica.
Por eso un pequeño negocio no debería construir una infraestructura compleja de pagos simplemente porque puede hacerlo.
Por ejemplo, SumUp dispone de distintas fórmulas para cobrar por internet, desde soluciones alojadas hasta componentes integrados. Puedes revisar las opciones en nuestra guía de pagos online con SumUp. La cuestión importante desde la perspectiva PCI no es solo qué proveedor utilizas, sino cómo está construida la integración concreta que utilizas.
Los 12 requisitos de PCI DSS explicados sin lenguaje de auditoría
PCI DSS se organiza alrededor de 12 grandes requisitos. No necesitas memorizar sus números para gestionar un pequeño negocio, pero sí entender qué persiguen.
El PCI Security Standards Council agrupa esos requisitos alrededor de redes seguras, protección de datos, gestión de vulnerabilidades, control de accesos, monitorización y políticas de seguridad.
Puedes consultar también el resumen oficial de los 12 requisitos de seguridad PCI DSS.
| Requisito | Traducido a la realidad de un comercio |
|---|---|
| 1. Controles de seguridad de red | Evitar que tus sistemas estén innecesariamente expuestos |
| 2. Configuraciones seguras | No trabajar con ajustes o credenciales inseguras por defecto |
| 3. Proteger datos almacenados | No guardar información sensible sin necesidad y proteger la que sí corresponda conservar |
| 4. Proteger datos durante la transmisión | Evitar que viajen de forma insegura por redes abiertas |
| 5. Protección frente a software malicioso | Mantener equipos y sistemas protegidos |
| 6. Sistemas y software seguros | Actualizar, corregir vulnerabilidades y desarrollar de forma segura |
| 7. Limitar el acceso | Solo debe acceder quien realmente lo necesita |
| 8. Identificar y autenticar usuarios | Evitar cuentas compartidas y accesos débiles |
| 9. Seguridad física | Proteger terminales, equipos y soportes |
| 10. Registrar y monitorizar | Poder detectar accesos o comportamientos anómalos |
| 11. Probar la seguridad | Comprobar periódicamente que las defensas funcionan |
| 12. Gestionar la seguridad | Definir responsabilidades, procedimientos y formación |
Para una empresa grande, cada uno de estos requisitos puede traducirse en numerosos controles técnicos.
Para una tienda pequeña, el objetivo práctico debería ser otro: evitar crear un entorno innecesariamente complejo.
Si no necesitas que los números de tarjeta lleguen a tu servidor, no diseñes el pago para que lleguen. Si un empleado no necesita acceder a determinada información, no le des ese acceso.
Reducir el alcance suele ser más eficaz que intentar proteger una colección de sistemas que nunca necesitaste tener dentro del proceso de pago.
SAQ, AOC, ASV y ROC: qué puede pedirte realmente PCI DSS
Esta parte suele sonar mucho más complicada de lo que es porque está llena de siglas.
SAQ: cuestionario de autoevaluación
Un SAQ o Self-Assessment Questionnaire es una herramienta para que determinados comercios evalúen y documenten su cumplimiento cuando cumplen los criterios establecidos para utilizar ese cuestionario.
No existe un único SAQ válido para cualquier negocio.
Hay diferentes modalidades porque no tiene el mismo entorno una tienda que utiliza determinados terminales presenciales que un ecommerce que externaliza todo el procesamiento.
PCI SSC recomienda confirmar con el adquirente o con la entidad que recibirá la documentación si puedes utilizar un SAQ y cuál corresponde a tu entorno.
AOC: declaración de cumplimiento
El AOC o Attestation of Compliance es la declaración formal asociada al proceso de evaluación.
No conviene confundirla con uno de esos “certificados PCI” comerciales que pueden aparecer en internet. PCI SSC aclara que los certificados genéricos emitidos fuera de sus formularios oficiales no son la documentación reconocida para validar PCI DSS.
ASV: escaneos externos de vulnerabilidades
Un Approved Scanning Vendor o ASV es un proveedor autorizado por PCI SSC para efectuar determinados escaneos externos de vulnerabilidades.
No todos los pequeños comercios necesitan exactamente los mismos escaneos. Su aplicación depende del entorno y de los requisitos que correspondan.
En ecommerce hay una lección importante: externalizar el formulario de pago no implica necesariamente que puedas olvidarte por completo de la seguridad de tu propia web.
ROC: una evaluación mucho más amplia
Un Report on Compliance o ROC es un informe de evaluación más amplio utilizado en entornos donde ese nivel de validación es requerido.
Un pequeño comercio no debería asumir que necesita un ROC simplemente porque acepta tarjetas, del mismo modo que tampoco debería asumir que le basta siempre con el SAQ más sencillo.
La pregunta correcta es:
¿Qué procedimiento de validación me exige la entidad que gestiona mi cumplimiento y encaja realmente con mi entorno de pago?
Qué debería hacer un pequeño comercio para cumplir con PCI DSS
En vez de empezar descargando cuestionarios, empieza dibujando cómo cobras.
Un folio es suficiente.
Por ejemplo:
Cliente → datáfono → proveedor de pagos
o:
Cliente → tienda online → checkout externo → proveedor de pagos
o:
Cliente → formulario propio → servidor del comercio → proveedor
Solo con este esquema puedes descubrir si tu negocio está tocando datos que no necesita tocar.
Checklist práctico
- Identifica todos tus canales de pago. No olvides tienda física, web, enlaces de pago, reservas o cobros telefónicos.
- Comprueba dónde se introducen los datos de tarjeta.
- Detecta si algún dato acaba en tu software, correo, documentos o dispositivos.
- Elimina cualquier almacenamiento innecesario.
- Identifica a todos los proveedores que intervienen en el cobro.
- Comprueba qué servicios de esos proveedores están cubiertos por su cumplimiento PCI DSS.
- Confirma con tu adquirente qué validación debes presentar.
- Limita los accesos del personal a lo estrictamente necesario.
- Mantén actualizados terminales, ecommerce, plugins y sistemas relacionados con los pagos.
- Revisa periódicamente datáfonos y dispositivos para detectar manipulaciones.
- Forma al personal para que no copie datos de tarjeta en lugares inadecuados.
- Repite la revisión cuando cambies de proveedor, web o sistema de pago.
Un comercio que hace bien estos doce pasos parte de una posición mucho mejor que otro que simplemente descarga un documento PCI y empieza a marcar casillas sin entender su infraestructura.
Errores de seguridad que deberías eliminar antes de preocuparte por el papeleo
Hay malas prácticas que complican el cumplimiento y, sobre todo, aumentan el riesgo real.
Una bastante evidente es recibir números de tarjeta por correo electrónico, WhatsApp o formularios improvisados.
Otra es apuntarlos temporalmente en papel, una hoja de cálculo o una nota para realizar el cobro más tarde.
También es habitual encontrar contraseñas compartidas entre empleados, cuentas de administrador utilizadas por todo el equipo, plugins abandonados durante meses sin actualizar o datáfonos que nadie revisa físicamente.
Señal de alerta: si para cobrar tienes que copiar información de una tarjeta de un sistema a otro manualmente, merece la pena revisar el proceso.
El mejor control de seguridad para un dato sensible muchas veces consiste en no tener ese dato.
Tu proveedor de pagos no puede proteger lo que haces fuera de su entorno
Supongamos que utilizas una pasarela perfectamente preparada, pero un empleado pide a un cliente que envíe su tarjeta por email porque el pago ha fallado.
El problema ya no está en la pasarela.
Lo mismo ocurre si tu checkout está externalizado pero dejas tu web desactualizada o con usuarios administradores compartidos.
La seguridad es una cadena. Externalizar correctamente una parte del pago reduce riesgos, pero no corrige malas prácticas en las partes que siguen bajo tu control.
Elegir un TPV también es una decisión de seguridad
Al comparar una solución de cobro es normal mirar primero el precio. Pero una diferencia pequeña de comisión importa poco si el proveedor te obliga a mantener un sistema que no entiendes o añade una complejidad innecesaria.
Antes de contratar, revisa:
- quién procesa realmente los pagos;
- cómo se capturan los datos de tarjeta;
- qué parte del cumplimiento asume el proveedor;
- qué responsabilidades conserva tu negocio;
- cómo se gestionan actualizaciones y dispositivos;
- qué soporte recibirás si hay una incidencia;
- qué coste total tendrá el sistema.
Nuestra guía de comisiones de los TPV te ayuda con la parte económica, pero precio y seguridad deberían evaluarse juntos, no por separado.
Si todavía estás decidiendo qué sistema encaja con tu negocio, puedes comparar los TPV para comercios o revisar nuestra selección de mejores datáfonos y TPV para negocios.
Y si prefieres comprar el dispositivo en lugar de depender de un terminal suministrado por una entidad, revisa primero cómo funcionan los datáfonos libres. Tener el hardware en propiedad no significa que puedas conectarlo a cualquier procesador ni cambia por sí solo tus obligaciones de seguridad.
Conclusión
PCI DSS parece complejo cuando se empieza por sus siglas, formularios y requisitos. Para un comercio es mucho más fácil entenderlo empezando por una pregunta: ¿por dónde pasan los datos de la tarjeta cuando alguien me paga?
A partir de ahí, la estrategia más sensata es reducir al mínimo el contacto con esos datos, utilizar proveedores adecuados, proteger los sistemas que siguen bajo tu control y confirmar con tu adquirente qué forma de validación corresponde a tu negocio.
No necesitas convertir tu tienda en un departamento de ciberseguridad. Pero tampoco deberías asumir que el proveedor se encarga de absolutamente todo. Cuanto más sencillo y controlado sea tu flujo de pago, más fácil será proteger a tus clientes y gestionar PCI DSS con criterio.
