PCI DSS para un directorio de anuncios para adultos: que decide realmente cuanto trabajo de cumplimiento te toca
Conseguir que una pasarela de pago acepte un sitio de anuncios para adultos ya es una batalla en si misma, y una vez ganada, casi todos los operadores dan por hecho que lo dificil ha terminado. No es asi. La cuenta que por fin dice que si trae consigo una obligacion permanente que no tiene nada que ver con la verificacion de edad, la moderacion, ni ninguna de las normas que pueda imponer un estado o un buscador. Es un estandar de seguridad escrito por los propios circuitos de tarjetas, y se aplica desde el momento en que un numero de tarjeta toca cualquier parte de tu negocio, por pequeno que sea.
Lo que sigue no es asesoramiento legal, y cualquiera que maneje datos reales de tarjeta deberia hacer revisar su caso por un Qualified Security Assessor. Es la forma de una decision que casi ningun operador se da cuenta de estar tomando, porque quien la toma por el suele ser un desarrollador que quiere construir una pagina de pago mas cuidada, mucho antes de que la pregunta llegue al lado comercial de la empresa.
La norma que firmaste sin leer
El PCI DSS, el estandar de seguridad de datos de la industria de tarjetas de pago, no es una ley y ninguna agencia estatal lo hace cumplir. Es una obligacion contractual escrita en el acuerdo que cada comercio firma con un banco adquirente o un facilitador de pagos, y existe porque Visa, Mastercard y los demas circuitos exigen a sus adquirentes que lo trasladen a cualquier negocio que almacene, procese o transmita un numero de tarjeta. El propio organismo del estandar es explicito: se aplica a cualquier entidad que maneje datos de tarjeta, ya sea directamente o a traves de un tercero, sin excepcion por tamano ni por volumen de transacciones.
Es una pregunta distinta de la que hace un proveedor de pagos antes de abrirte una cuenta. Lo que un proveedor quiere saber antes de aceptar trabajar contigo tiene que ver con el negocio en si: quien es su dueno, como se revisan los anuncios, como se verifica a los anunciantes. El PCI DSS empieza despues de que esa cuenta existe, y en la practica no termina nunca. Se renueva cada ano mientras el negocio acepte tarjetas, y cambia de forma cada vez que cambia el modo en que se aceptan.
El volumen de transacciones si importa, aunque no del modo en que se suele pensar. Determina un "nivel" de comercio, del uno al cuatro, y ese nivel decide como se valida el cumplimiento: un operador pequeno rellena un cuestionario de autoevaluacion, mientras que un negocio que procesa millones de transacciones al ano necesita un auditor externo. Lo que el volumen no hace es eximir a nadie. Un comercio de alto riesgo que procesa unos pocos cientos de transacciones al mes esta sujeto exactamente al mismo estandar de fondo que una gran cadena, solo que validado con un formulario mas corto.
La unica decision que fija tu carga de trabajo durante anos
El formulario que se aplica a un negocio concreto no se elige libremente. Lo determina por completo un hecho tecnico: si el numero de tarjeta, en algun punto del recorrido, pasa por un sistema controlado por el operador. Enviar al cliente a una pagina de pago alojada por el proveedor, o insertar un iframe de pago correctamente aislado que ese proveedor suministra, hace que el numero de tarjeta nunca toque el servidor propio del operador. Construir en cambio un formulario de pago que recoge el numero de tarjeta y lo envia al backend propio antes de reenviarlo, aunque sea por un instante, hace que si lo toque.
Ese unico hecho separa el cuestionario mas ligero del mas pesado por un orden de magnitud. La via totalmente externalizada, conocida como SAQ A, ronda las veinte preguntas. La via en la que la propia pagina del operador entrega o influye en parte del proceso de pago, incluso sin tocar directamente el numero de tarjeta, como un formulario alojado por el propio operador cuyos campos reenvian los datos, cae en SAQ A-EP, cerca de las doscientas preguntas. Almacenar, procesar o transmitir de verdad los datos de la tarjeta en los propios sistemas cae en SAQ D, que cubre el conjunto completo de controles del estandar: cifrado, gestion de claves, segmentacion de red, registro de accesos, control de accesos, todo, con varios cientos de puntos.
Vale la pena aclarar de entrada un malentendido frecuente. Usar un iframe de un proveedor conforme no hace que un sitio caiga automaticamente en el nivel mas pesado de SAQ A-EP: un iframe de terceros correctamente aislado, en el que la pagina propia del operador no aporta ningun codigo capaz de ver o tocar los campos de pago, sigue calificando en general para la via ligera de SAQ A. Lo que sube a un negocio de nivel es el propio codigo del operador metiendose en esa pagina, ya sea un formulario construido por cuenta propia, un script anadido para "mejorar" el pago, o una integracion de estilo antiguo en la que el navegador envia los datos de la tarjeta a traves de codigo escrito por el operador y no por el proveedor.
Lo que la via ligera sigue exigiendo, desde hace un ano
Merece la pena corregir una creencia que antes era cierta y ya no lo es. Los operadores que eligieron la via externalizada aprendieron, con razon, que eso los mantenia fuera de la mayor parte de la carga tecnica del estandar, y algunos aun creen que eso significa ninguna revision de seguridad periodica. Desde la version 4.0.1 del PCI DSS, exigible desde abril de 2025, ya no es asi. SAQ A incluye ahora un requisito de analisis trimestrales de vulnerabilidades externas por parte de un Approved Scanning Vendor, ejecutados contra el propio sitio del operador, el que aloja la redireccion o el iframe, aunque ese sitio nunca vea un numero de tarjeta.
El razonamiento detras del cambio es sencillo una vez que se dice en voz alta: la pagina que envia al cliente hacia el procesador de pagos sigue formando parte de la superficie de ataque. Una pagina de pago comprometida puede redirigir a un cliente a un sitio distinto del procesador real, o cargar un script malicioso que lee los datos de la tarjeta directamente del navegador antes de que el iframe llegue a cargar, un patron de ataque que ya ha golpeado a comercios reales. De la misma logica se derivan dos requisitos relacionados: el operador debe mantener un inventario de cada script que corre en la pagina de pago, y detectar cambios no autorizados en el contenido de esa pagina, obligaciones que aplican en SAQ A precisamente porque la pagina de pago es del operador, aunque el numero de tarjeta nunca lo haya sido.
Lo que la via ligera sigue evitando, y esta es la brecha que de verdad importa, es la prueba de penetracion anual exigida en SAQ A-EP y SAQ D, junto con los controles internos profundos que esos niveles requieren: cifrar los datos de tarjeta almacenados, gestionar las claves que los protegen, segmentar la red alrededor de cualquier sistema que los toque, y registrar en detalle todo acceso. Elegir la via externalizada no significa ningun trabajo de seguridad. Significa unas pocas horas de analisis e higiene de scripts al ano en lugar de un programa de seguridad permanente construido alrededor de datos que el negocio tendria que almacenar de otro modo.
Lo que cuesta hacerlo mal
Nada de esto lo hace cumplir un tribunal ni un regulador, y esa es parte de la razon por la que resulta facil subestimarlo. Los circuitos multan al banco adquirente cuando un comercio de su cartera no es conforme, y el adquirente traslada ese coste directamente al comercio a traves del contrato, empezando normalmente por cifras modestas y subiendo cuanto mas se prolonga el incumplimiento. No existe una tabla publica que fije estas cifras para cada adquirente, porque el acuerdo vive dentro de contratos privados y no de normas publicas, pero la direccion es constante: la multa crece con el tiempo, no con lo bien que el negocio explique el retraso.
Ese es el coste de simplemente no estar en cumplimiento. Una violacion real, en la que se exponen numeros de tarjeta almacenados porque un operador estaba manejando datos que SAQ A estaba pensado precisamente para evitarle, es un gasto de otro orden por completo. Los circuitos pueden exigir una investigacion forense por parte de una firma especializada antes de que nadie pueda reabrir la cuenta, pagada por el comercio sea cual sea el resultado, y las tarjetas afectadas se reemiten a costa del comercio. Un seguro de responsabilidad cibernetica rara vez cubre este tipo de agujero para un negocio como este, ya que el contenido para adultos figura en la lista de sectores excluidos de mas de una poliza cibernetica de grandes aseguradoras, lo que significa que la exposicion descrita aqui esta muy a menudo sin asegurar, no solo resulta cara.
La consecuencia mas duradera no es la multa ni siquiera la investigacion. Es la decision del adquirente, una vez que una violacion o un incumplimiento prolongado consta en el expediente, de cerrar la cuenta en lugar de seguir asumiendo el riesgo, y de registrar ese cierre de un modo que otros adquirentes pueden ver antes de abrir una nueva. Una relacion de pagos que costo meses construir la primera vez es mucho mas dificil de reconstruir con ese historial pegado al negocio.
Que hacer este mes
Empieza por averiguar, por escrito, que cuestionario se aplica realmente hoy. Preguntalo directamente al proveedor de pagos en lugar de dar la respuesta por supuesta: confirma si el pago actual es una redireccion, un iframe correctamente aislado, o algo que toca el servidor propio del operador en algun punto del recorrido, porque la respuesta a esa pregunta es todo el programa de cumplimiento resumido en una frase. Consiguelo por correo electronico, no por telefono, porque es el punto de referencia para cada decision que venga despues.
Trata cualquier peticion de cambiar como se recogen las tarjetas como una cuestion de cumplimiento antes que de diseno. Un desarrollador que quiere construir un formulario de pago a medida porque la pagina alojada parece generica, o que anade un chat o un script de analitica a la misma pagina que aloja el iframe de pago, esta tomando una decision PCI, lo plantee alguien asi o no. Revisa ese tipo de cambio antes de que se publique, no despues de que un analisis lo senale.
Presenta la atestacion anual dentro de plazo y guarda los resultados de cada analisis trimestral, incluso los aburridos en los que nada cambia, porque una atestacion caducada se lee, a ojos de un adquirente, exactamente igual que no haberla presentado nunca. Nada de esto es dificil cuando la arquitectura de base es la correcta. Un pago construido una vez alrededor de una pagina alojada o de un iframe correctamente aislado convierte todo esto en una tarde de papeleo, repetida una vez al ano. Un pago que ha ido adquiriendo poco a poco el habito de tocar datos de tarjeta convierte la misma obligacion en un programa de seguridad permanente que el negocio nunca planeo gestionar.
