Las cifras que importan
Si gestiona un hotel independiente, esta es la situación a fecha de publicación de este artículo. La norma PCI DSS v4.0 pasó a ser obligatoria el 31 de marzo de 2024, cuando el Consejo de Normas de Seguridad PCI retiró la versión v3.2.1. La propia norma PCI DSS v4.0 fue retirada a su vez el 31 de diciembre de 2024 y sustituida por la v4.0.1, que es la única versión activa actualmente de la norma. Y el 31 de marzo de 2025, los 51 requisitos que se habían clasificado como «buenas prácticas con fecha futura» pasaron a ser obligatorios sin periodo de gracia. Si su última autoevaluación se realizó con respecto a cualquier versión anterior, o con respecto a la v4.0 con los requisitos con fecha futura marcados como «No aplicable», usted incumple la normativa en el momento de escribir este artículo.
La mayoría de los hoteleros independientes con los que hablo no saben esto. Los que sí lo saben, suelen tener una idea difusa que les permite seguir posponiéndolo. Saben que «algo pasó con PCI en 2025». No están seguros de si les afecta. Sospechan que su procesador de pagos se encarga de ello. En su mayoría, se equivocan en los tres puntos.
El funcionamiento es sencillo. Las redes de tarjetas (Visa, Mastercard, American Express, Discover, JCB) establecen el cumplimiento como una condición contractual para aceptar sus tarjetas. Tu banco adquirente te transfiere ese contrato. Si incumples la normativa y tu adquirente se da cuenta, el banco puede repercutirte tasas por incumplimiento que comienzan en 5.000 dólares al mes durante los meses uno a tres, aumentan a entre 25.000 y 50.000 dólares al mes durante los meses cuatro a seis, y alcanzan entre 50.000 y 100.000 dólares al mes a partir del séptimo mes, según los baremos publicados recopilados a partir de las medidas coercitivas de los adquirentes en 2024 y 2025. Si incumple la normativa y además sufre una filtración de datos, las sanciones por compromiso de datos de cuentas solo de Visa comienzan en 50 000 dólares por incidente para un comerciante que incumpla la normativa y pueden llegar hasta los 500 000 dólares, con sanciones paralelas de Mastercard. Ninguna de estas cifras es teórica. El acuerdo por la filtración de Marriott y Starwood, formalizado por la Comisión Federal de Comercio de EE. UU. el 20 de diciembre de 2024, incluía un acuerdo paralelo de 52 millones de dólares con 49 fiscales generales estatales, y la multa relacionada de 18,4 millones de libras esterlinas por incumplimiento del RGPD impuesta por la Oficina del Comisionado de Información del Reino Unido en 2020 elevó los daños acumulados de esa filtración a una cifra de nueve dígitos, sin contar los costes legales y de reparación.
Esa es la parte negativa. La parte positiva es que, para un hotel independiente medio de entre 30 y 150 habitaciones que utilice un procesador de pagos con tokenización, alcanzar y mantener el cumplimiento normativo cuesta entre 1500 y 3000 dólares al año, requiere que una persona dedique unos 90 días a ponerlo todo en marcha la primera vez, y no exige ningún QSA, ningún contrato de consultoría ni ninguna plataforma de seguridad empresarial. La diferencia entre 1500 dólares al año y una multa mensual de cinco cifras es, como se puede imaginar, el tema central de este artículo.
Esta es una visión honesta de la norma PCI DSS 4.0 para hoteles independientes en 2026. Las cuatro mentiras que los hoteleros se cuentan a sí mismos al respecto, cómo elegir el Cuestionario de Autoevaluación adecuado (que es la decisión más importante que tomará), los diez nuevos requisitos en los que los hoteles suelen fallar con más frecuencia, los siete lugares de su hotel donde se esconden datos de tarjetas y que ha olvidado, los rangos de costes reales con fuentes, y un plan de 90 días que una persona con mentalidad operativa puede llevar a cabo sin ayuda externa.
Qué ha cambiado y por qué no ha cumplido el plazo
La razón por la que los operadores hoteleros no cumplieron el plazo de la PCI DSS 4.0 no es la pereza. Es que el PCI Security Standards Council comunicó mal la transición, y la prensa especializada en hostelería la cubrió aún peor. Aquí tienes la secuencia real para que dejes de estar confundido sobre en qué versión se supone que debes estar.
La norma PCI DSS v3.2.1 se publicó en mayo de 2018 y siguió siendo la versión activa de la norma durante casi seis años. La mayoría de los cuestionarios de autoevaluación (SAQ) de hoteles presentados entre 2018 y 2024 hacían referencia a la v3.2.1. La norma PCI DSS v4.0 se publicó el 31 de marzo de 2022 con un periodo de solapamiento de dos años durante el cual tanto la v3.2.1 como la v4.0 estuvieron vigentes. La v3.2.1 quedó obsoleta el 31 de marzo de 2024. A partir de esa fecha, cualquier evaluación de la norma PCI DSS debía realizarse según la v4.0.
La v4.0 introdujo 64 nuevos requisitos. 13 de ellos entraron en vigor inmediatamente tras su publicación. Los otros 51 se designaron como «buenas prácticas con fecha futura» con un plazo de tres años. Se permitió a los hoteles y a sus evaluadores marcar los 51 requisitos con fecha futura como «No aplicable» en las evaluaciones realizadas entre el 31 de marzo de 2022 y el 31 de marzo de 2025, con una nota documentada de que se abordarían antes de la fecha límite. La mayoría de los hoteles hicieron exactamente eso y luego se olvidaron de ellos.
En junio de 2024, el PCI SSC publicó la v4.0.1, que es una revisión limitada de la v4.0 con correcciones de formato, notas de aplicabilidad aclaradas y sin requisitos añadidos ni eliminados. La v4.0 quedó retirada el 31 de diciembre de 2024, y la v4.0.1 se convirtió en la única versión activa actualmente. La fecha límite del 31 de marzo de 2025 para los 51 requisitos con fecha futura no se modificó con la revisión v4.0.1 y el PCI SSC fue explícito al respecto en sus preguntas frecuentes publicadas.
Ese plazo ya ha vencido. A partir del 1 de abril de 2025, los 51 requisitos que antes tenían fecha futura son obligatorios y deben validarse con pruebas durante cada evaluación del PCI DSS. No hay periodo de gracia, no se aceptan medidas de mitigación temporales, y se ha indicado a los evaluadores de seguridad cualificados que verifiquen no solo que los controles se hayan implementado, sino que estuvieran operativos antes de la fecha límite, en lugar de haberse implementado a toda prisa la semana anterior. Si el SAQ más reciente de su hotel marcó esos 51 requisitos como «No aplicable», usted incumple la normativa desde el momento en que lo presentó.
Las cuatro áreas de control que absorben más tiempo a los operadores, y que suelen pasarse por alto con mayor frecuencia, se detallan más adelante. Pero el resumen más útil que puedo ofrecerte aquí es este: si no has abierto tu último SAQ en los últimos 12 meses, es casi seguro que necesitas presentar uno nuevo. Si su último SAQ fue un SAQ A, las normas sobre lo que cumple los requisitos para el SAQ A se han endurecido (más información al respecto a continuación). Y si su hotel sigue enviando por correo electrónico los datos de tarjetas de crédito virtuales en texto sin cifrar, ha estado infringiendo el Requisito 4.2.1 desde el día en que puso en marcha su motor de reservas. Ninguna de estas afirmaciones es especulativa. Son el texto publicado y vigente de la norma PCI DSS v4.0.1.
Las cuatro mentiras que los hoteles se cuentan a sí mismos sobre PCI
Antes de pasar a las orientaciones prácticas, las cuatro autoengaños que escucho en casi todas las conversaciones sobre PCI con un hotelero independiente. Ninguna de ellas es absurda. Todas eran interpretaciones razonables de la norma PCI DSS v3.2.1 y de la cultura de aplicación más laxa de 2018 a 2023. Ya no son ciertas bajo la v4.0.1 y la aplicación a partir de 2025.
1. «Nuestro procesador de pagos se encarga del cumplimiento por nosotros»
Su procesador de pagos se encarga de su propio cumplimiento de PCI. No se encarga del suyo. La norma PCI DSS traza una línea legal clara entre un proveedor de servicios externo (TPSP), como su adquirente, su pasarela o su procesador de tokenización, y usted, el comerciante. El TPSP es responsable de los datos de los titulares de tarjetas que circulan por su entorno y de completar su propio SAQ D para proveedores de servicios. Usted, el comerciante, es responsable de los datos de los titulares de tarjetas que pasan por su entorno, de las integraciones que gestiona y de completar su propio SAQ. Las dos responsabilidades no se solapan y no existe ninguna versión de «nuestro procesador se encarga de ello» que sea contractualmente cierta. Lo que su procesador puede hacer es venderle una arquitectura en la que su entorno absorba la mayor parte del alcance de los datos de los titulares de tarjetas, lo que a su vez le permite completar un SAQ mucho más breve. Ese es el valor real de utilizar un procesador de tokenización, y es un valor real, pero no es lo mismo que externalizar su cumplimiento normativo.
2. «Cumplimos los requisitos para el SAQ A porque nuestro motor de reservas está alojado»
El SAQ A es el más sencillo de los ocho tipos de SAQ y se aplica a los comerciantes que han externalizado por completo el almacenamiento, el procesamiento y la transmisión de los datos de los titulares de tarjetas a un tercero que cumple con el PCI DSS, sin almacenamiento ni transmisión electrónica en los propios sistemas del comerciante. Los comerciantes del SAQ A solo pueden conservar los datos de los titulares de tarjetas en papel (informes impresos, recibos) y estos registros en papel no pueden recibirse electrónicamente. En el caso concreto de un canal de comercio electrónico, todos los elementos de la página de pago que se envían al navegador del cliente deben proceder única y directamente de un proveedor de servicios externo que cumpla con la norma PCI DSS. Ese es el texto literal de los criterios de elegibilidad del SAQ A v4.0.1.
El PCI SSC endureció aún más los criterios de elegibilidad del SAQ A en enero de 2025 con un nuevo requisito de certificación de que el sitio de comercio electrónico del comerciante no sea susceptible de sufrir ataques basados en scripts. En la práctica, esto significa que incluso los hoteles que utilizan un motor de reservas totalmente alojado con pago basado en iframes ya no pueden eludir los requisitos 6.4.3 y 11.6.1 si el resto de su sitio de reservas carga scripts de terceros que, en principio, podrían afectar a la página de pago. La mayoría de los sitios web de hoteles independientes cargan este tipo de scripts (herramientas de análisis, widgets de chat, píxeles de marketing, widgets de reseñas), por lo que la vía del SAQ A es más limitada de lo que parece. Volveremos sobre esto en la sección de selección del SAQ.
3. «Somos demasiado pequeños para ser un objetivo»
El Informe de Investigaciones sobre Fugas de Datos de Verizon de 2024 clasifica al sector hotelero como una de las cinco industrias con más fugas de datos por organización, y la víctima media no es una cadena. Los atacantes prefieren los pequeños hoteles independientes por una sencilla razón económica: el rendimiento por incidente (alrededor de 12 000 números de tarjeta al año para un hotel de 60 habitaciones con una ocupación del 75 %) es suficiente para que merezca la pena el esfuerzo, mientras que la postura defensiva suele estar una década por detrás de lo que desplegaría un equipo de seguridad empresarial. Los atacantes también saben que el hotel independiente medio no detectará un ataque de skimming en la página de pago al estilo Magecart durante meses. El tiempo medio de permanencia en las brechas de seguridad del sector hotelero investigadas por Verizon supera los 200 días. La combinación de «larga permanencia, detección débil y alto rendimiento de tarjetas por empleado» es precisamente la razón por la que los hoteles son el objetivo.
4. «Nunca hemos sufrido una violación de seguridad, así que debemos estar a salvo»
Esta es la más fácil de desmontar: el tiempo medio de permanencia de una violación de tarjetas de pago en el sector hotelero es, de nuevo, de más de 200 días. La ausencia de una violación conocida no es prueba de seguridad. es prueba de que no sabes si has sufrido una violación, lo cual es una afirmación muy diferente. La mayoría de los hoteles que han sufrido una filtración se enteraron a través de su banco adquirente, que a su vez lo descubrió mediante un análisis de Common Point of Purchase tras recibir una notificación de fraude en tarjetas utilizadas en el hotel. En ese momento, el tiempo de permanencia suele ser de nueve a doce meses y la violación ha estado activa de forma silenciosa durante todo ese periodo. El requisito 10.4.1.1 de la norma PCI DSS 4.0.1 se añadió específicamente para situar la revisión automatizada de registros al frente de la cadena de detección, de modo que los hoteles puedan dejar de enterarse de sus propias violaciones a través de su banco.
Elija correctamente su SAQ (esto lo es todo)
La decisión más trascendental en su programa PCI es qué SAQ rellena. Una elección errónea le costará, en el peor de los casos: una evaluación fallida (lo que convierte a su hotel en no conforme de la noche a la mañana), decenas de miles de dólares al año en gastos generales de cumplimiento innecesarios y una superficie de ataque mucho mayor para una violación real. La elección correcta suele ser obvia una vez que se mapea el flujo de datos de las tarjetas, algo que la mayoría de los hoteles nunca han hecho realmente.
Los ocho tipos de SAQ de la versión 4.0.1, con el número de preguntas y el escenario típico de hotel que se corresponde con cada uno:
- SAQ A (unas 30 preguntas): Comercio electrónico puro con todos los datos de tarjetas totalmente externalizados a un TPSP validado por PCI DSS. Sin almacenamiento, procesamiento ni transmisión electrónicos en los sistemas del hotel. El motor de reservas, la página de pago y la tokenización se ejecutan en la infraestructura del procesador. El hotel solo ve una referencia de token. La mayoría de los hoteles boutique independientes que utilizan Stripe, Adyen, Mews Payments, Cloudbeds Payments o Prostay Pay con un proceso de pago basado en iframes encajan aquí, siempre que también cumplan con la nueva certificación de enero de 2025 de que el sitio no es susceptible de sufrir ataques basados en scripts.
- SAQ A-EP (unas 190 preguntas): comercio electrónico parcialmente externalizado. El sitio web del comerciante afecta a la seguridad de la transacción de pago (por ejemplo, un flujo de redireccionamiento y retorno en el que la página del hotel transfiere el navegador al procesador y lo recupera), pero el comerciante sigue sin almacenar, procesar ni transmitir electrónicamente los datos del titular de la tarjeta por sí mismo. Aquí es donde se encuentran la mayoría de los hoteles en la actualidad, aunque crean que se ajustan al SAQ A.
- SAQ B (unas 40 preguntas): Solo terminales independientes con conexión telefónica, sin almacenamiento electrónico de datos de los titulares de tarjetas. Quedará obsoleto en 2026.
- SAQ B-IP (unas 80 preguntas): Terminales independientes homologadas por la PIN Transaction Security con conectividad IP, sin almacenamiento electrónico de datos de los titulares de tarjetas. Este es el SAQ adecuado para un hotel que realiza la mayoría de los pagos a través de un terminal EMV de mostrador fijo que se conecta directamente al procesador y nunca se integra con el PMS.
- SAQ C (unas 160 preguntas): Sistemas de aplicaciones de pago conectados a Internet, sin almacenamiento electrónico de datos de titulares de tarjetas. Algunas implementaciones de TPV en hoteles encajan aquí.
- SAQ C-VT (unas 80 preguntas): Introducción manual de transacciones individuales a través de un terminal virtual proporcionado por un TPSP. Esto se ajusta a un hotel pequeño en el que la recepción introduce los números de las tarjetas en un terminal web alojado de una en una, sin presencia de otros datos electrónicos de los titulares de tarjetas.
- SAQ D (Comerciante) (unas 330 preguntas): Todo lo demás. Cualquier almacenamiento electrónico de datos de titulares de tarjetas en los sistemas del hotel te sitúa automáticamente aquí.
- SAQ D (Proveedor de servicios) (unas 330 preguntas): Para proveedores de servicios. No se aplica a hoteles que actúan como comerciantes.
Para un hotel independiente típico de 60 habitaciones en 2026 con un motor de reservas alojado, un terminal EMV en recepción y sin datos de tarjetas almacenados en el PMS, el SAQ adecuado es el SAQ A o el SAQ B-IP, dependiendo de qué canal de pago se considere principal. El SAQ incorrecto para ese hotel es el SAQ D, que la mayoría de los contables elegirán instintivamente porque asumen que el cuestionario más largo es «más seguro». El SAQ D no es más seguro. Aplica un conjunto de requisitos mucho más amplio que, en realidad, no se puede cumplir sin una infraestructura empresarial, y los evaluadores ahora están capacitados para rechazar a los comerciantes que se autoeligen el SAQ D sin tener una razón documentada.
Lo más importante que puede hacer en los próximos 30 días es trazar un mapa del flujo de datos de tarjetas en papel, identificar el SAQ que realmente se aplica y documentar por qué se aplica. Si ese ejercicio de mapeo revela que algún sistema del hotel almacena, procesa o transmite electrónicamente datos de titulares de tarjetas (lo cual es casi seguro, más información al respecto en la sección «Los datos de las tarjetas se esconden en su hotel»), su verdadera tarea antes de presentar un SAQ es eliminar esa estructura, no presentar un SAQ D y conformarse con una mayor superficie de exposición.
Los diez nuevos requisitos que los hoteles incumplen con mayor frecuencia
Los 51 requisitos con fecha futura que entraron en vigor el 31 de marzo de 2025 abarcan la totalidad de la norma de 12 requisitos. En los proyectos que he visto en hoteles independientes en 2025 y 2026, diez requisitos absorben aproximadamente el 80 % del trabajo de corrección. Aquí están, en el orden en que yo los abordaría, con el texto de control real de la v4.0.1 resumido en un lenguaje sencillo y el modo de incumplimiento típico de los hoteles para cada uno.
Requisito 4.2.1: acabar con el problema del correo electrónico con VCC en texto plano
El requisito 4.2.1 establece que los números de cuenta primarios solo deben transmitirse a través de redes públicas abiertas utilizando criptografía fuerte. Las «redes públicas abiertas» incluyen la Internet pública, lo que abarca todos los servidores de correo electrónico fuera de su entorno tokenizado. Los hoteles reciben habitualmente datos de tarjetas de crédito virtuales (VCC) de las OTA y los operadores turísticos en correos electrónicos de texto sin cifrar. Esto constituye una infracción desde la versión 1.0 de la norma PCI DSS en 2004. Sigue siendo una infracción según la versión 4.0.1. La encuesta del sector realizada por Antravia y publicada en 2026 reveló que casi uno de cada tres hoteles sigue recibiendo al menos algunos datos de VCC en correos electrónicos de texto sin cifrar y lo considera normal. No lo es. Solucione esto exigiendo que todas las VCC se envíen a través de la extranet segura de la OTA, una integración API o una solución de bandeja de entrada tokenizada. Las redes de tarjetas están auditando cada vez más este control directamente a través de la OTA, por lo que, si su adquirente aún no lo ha señalado, es casi seguro que su proveedor lo hará.
Requisitos 6.4.3 y 11.6.1: bloquear los scripts de la página de pago
Estos dos requisitos son el titular de la versión 4.0.1 para el comercio electrónico y se aplican a todos los sitios web de hoteles que aceptan pagos. El 6.4.3 es preventivo: cada script cargado y ejecutado en el navegador del cliente en una página de pago debe estar autorizado, tener su integridad verificada y aparecer en un inventario con una justificación técnica o comercial documentada. El 11.6.1 es de detección: debe implementarse un mecanismo de detección de cambios y manipulaciones que alerte al personal en un plazo de siete días si cambian los encabezados HTTP que afectan a la seguridad o el contenido de los scripts de la página de pago tal y como los recibe el navegador del consumidor.
El modo de fallo típico de los hoteles es que la página de reservas se carga con entre ocho y quince scripts de terceros (análisis, chat, retargeting, reseñas, marco de pruebas A/B, mapa de calor, gestor de consentimiento, píxeles sociales) y el hotel no dispone ni de un inventario ni de un mecanismo de detección de manipulaciones. La solución es concreta: reducir la lista de scripts de terceros al mínimo, documentar la justificación de cada script restante e implementar una herramienta de detección de cambios del lado del servidor, como Visualping, Feroot o PCI Pal, o un producto de gestión de scripts del lado del cliente, como Source Defense. Los encabezados de la Política de Seguridad de Contenidos y los hash de Integridad de Subrecursos forman parte de la respuesta correcta, pero la guía del PCI SSC deja claro que no son suficientes por sí solos. también se necesita supervisión.
Requisito 12.5.2: confirme su alcance PCI anualmente
El requisito 12.5.2 exige un ejercicio anual para confirmar el alcance de PCI y los componentes que lo integran (los proveedores de servicios deben hacerlo cada 6 meses). El ejercicio debe identificar todos los flujos de datos de titulares de tarjetas, todos los sistemas que almacenan, procesan o transmiten datos de titulares de tarjetas, y cualquier sistema que esté conectado a los datos de titulares de tarjetas o que pueda afectar a su seguridad. El DBIR de Verizon ha señalado en repetidas ocasiones que el 34 % de las violaciones de seguridad en hoteles se originan a partir de datos de tarjetas encontrados en lugares inesperados. El ejercicio de confirmación del alcance es el mecanismo que permite detectar esos lugares inesperados antes de que lo haga un atacante.
Requisitos 8.3.6 y 8.4.2: MFA para todo el acceso al CDE
En la versión 4.0.1, se requiere la autenticación multifactorial para todos los accesos que no sean desde la consola al entorno de datos de los titulares de tarjetas, incluido el acceso administrativo por parte del personal del hotel y de los proveedores de servicios externos. Esto va más allá de la línea de base de la versión 3.2.1 (que solo exigía la MFA para el acceso administrativo remoto desde fuera de la red) y es el requisito que rompe más con los hábitos de los administradores de hoteles. La solución consiste en implementar una MFA resistente al phishing (TOTP como mínimo, llaves de hardware FIDO2 para cuentas de administrador) en todas las cuentas del PMS, todos los inicios de sesión en pasarelas de pago, todos los inicios de sesión de administrador de routers y todas las cuentas de back-office en la nube que tengan contacto con el CDE.
Requisito 11.4.7: análisis de vulnerabilidades internos autenticados
Los análisis internos de vulnerabilidades deben realizarse ahora utilizando credenciales que permitan el acceso autenticado. Un análisis anónimo de su red ya no es suficiente. El impacto práctico es que debe ejecutar usted mismo un escáner interno con credenciales autenticadas (la mayoría de los hoteles no pueden hacerlo) o contratar a un socio QSA para que realice un análisis con credenciales cada trimestre. Prevea un presupuesto adicional de entre 500 y 2000 dólares al año para esto si no dispone de capacidad interna.
Requisito 12.6.3.1: formación específica en concienciación sobre seguridad
La formación en concienciación sobre seguridad debe abarcar ahora las amenazas y vulnerabilidades que podrían afectar a la seguridad del entorno de datos de los titulares de tarjetas, con contenido específico para las tecnologías y funciones incluidas en el ámbito de aplicación. Un vídeo genérico de «introducción al phishing» no cumple este requisito. Necesita contenido específico para cada función: un módulo diferente para el personal de recepción (centrado en la ingeniería social, el manejo de datos de tarjetas y el problema del VCC en texto plano), un módulo diferente para el back office (centrado en el control de acceso al PMS y el problema del archivo de faxes) y un módulo diferente para el departamento de TI o quienquiera que administre su motor de reservas. Documente la impartición y la finalización anualmente.
Requisitos 3.3.2 y 3.5.1.1: hash criptográficos con clave para el PAN
Si almacena datos de PAN en cualquier formato electrónico (por favor, no lo haga), los hash unidireccionales ya no son suficientes para que el PAN sea ilegible. Debe utilizar un hash criptográfico con clave con los procesos de gestión de claves asociados según los requisitos 3.6 y 3.7. En la práctica, esto casi nunca se aplica a un hotel que utilice un procesador de tokenización, ya que el hotel no debería tener un PAN que hash. La solución más clara es eliminar por completo el PAN de su entorno, lo que le sitúa en el ámbito de aplicación del SAQ A o del SAQ B-IP y elimina los requisitos 3.3.2 y 3.5.1.1, junto con la mayor parte del resto del requisito 3.
Requisitos 6.3.2 y 6.3.3: inventario de software a medida y personalizado, además de la aplicación de parches
Todo el software a medida y personalizado debe inventariarse y parchearse. Para la mayoría de los hoteles, esto pone de manifiesto una responsabilidad inesperada: el sitio de WordPress, Squarespace o el sitio de marketing a medida que la agencia de marketing creó en 2018, no se ha parcheado desde 2021 y que carga scripts en el flujo de reservas. La periodicidad de las actualizaciones en la versión 4.0.1 ha vuelto a la redacción de la versión 3.2.1: las vulnerabilidades críticas deben ser parcheadas en un plazo de 30 días. La solución consiste en mantener un inventario de software (una hoja de cálculo es suficiente para una empresa independiente), asignar un responsable por componente y, o bien aplicar las actualizaciones según lo previsto, o bien retirar el componente.
Requisito 10.4.1.1: revisión automatizada de registros
La revisión manual de registros ya no es aceptable para los requisitos de revisión diaria de la v4.0.1. Se necesita un mecanismo automatizado que recopile los registros del entorno de datos de los titulares de tarjetas y detecte anomalías. Para un pequeño independiente, esto puede ser tan sencillo como la función de registro de auditoría de su PMS en la nube (con alertas por correo electrónico sobre eventos sospechosos), además de las funciones de alerta del panel de control de su pasarela de pago. No es necesario un SIEM de 50 000 dólares al año, pero sí hay que demostrar que algo revisa los registros todos los días.
Requisito 12.10.7: procedimientos de respuesta a incidentes para PAN almacenados encontrados en lugares inesperados
Si su confirmación del alcance (12.5.2) encuentra datos PAN en un lugar donde no deberían estar, necesita un procedimiento documentado sobre cómo responder. Lo mínimo es: contener (aislar el sistema), evaluar (averiguar qué se ha expuesto y durante cuánto tiempo), notificar (a su adquirente dentro del plazo que este requiera, a menudo de 24 a 72 horas) y remediar (eliminar los datos y solucionar la causa). Redacte este procedimiento una vez, guárdelo donde el personal de guardia pueda encontrarlo a las 3 de la madrugada y revíselo anualmente.
Los siete lugares donde se esconden los datos de las tarjetas en su hotel
La cifra del 34 % del DBIR de Verizon que he citado anteriormente no es abstracta. En todos los proyectos de cumplimiento de la norma PCI en hoteles independientes en los que he participado en los últimos dos años, el ejercicio de confirmación del alcance ha revelado al menos tres de los siguientes siete lugares donde se encuentran los datos de los titulares de tarjetas, a menudo años después de que se guardaran allí y se olvidaran. Aquí está la lista, ordenada por frecuencia. Úsela como lista de verificación para su propio ejercicio 12.5.2.
- Archivo del servidor de correo electrónico. Cada correo electrónico con el VCC en texto plano enviado por una OTA, o cualquier huésped que en su día introdujera su número de tarjeta en un correo electrónico del tipo «Por favor, carguen el depósito a mi tarjeta», se encuentra en su archivo IMAP. Busque «número de tarjeta», «CVV», «caducidad» y el patrón de cuatro dígitos seguidos de un espacio. Se horrorizará con lo que encuentre.
- Copias de seguridad antiguas de la base de datos del PMS. Cada copia de seguridad nocturna del PMS creada antes de que su hotel cambiara a un procesador de tokenización probablemente contenga datos PAN completos. Revise su proveedor de copias de seguridad externo, el NAS de su hotel, el disco duro externo del gerente de recepción y la memoria USB sin cifrar que hay en la caja fuerte. Las copias de seguridad anteriores a 2019 son especialmente propensas a contener PAN sin procesar.
- Archivo de fax. Cada fax de VCC emitido por una OTA, cada formulario de autorización de reserva de grupo, cada formulario de autorización de pago con tarjeta de crédito que haya solicitado su departamento administrativo. Las impresoras multifunción modernas suelen tener un archivo de 500 faxes en su almacenamiento interno que nunca se ha borrado.
- Impresiones del archivo de folios. La pila de folios impresos en la oficina administrativa, el archivo encuadernado de folios de huéspedes anteriores a 2020, el archivador del gerente etiquetado como «copias de auditoría». Estos contienen datos de PAN impresos, lo que viola la norma «papel solo si no se recibe electrónicamente» del SAQ A, una vez que se da cuenta de que los folios fueron generados por un PMS electrónico.
- Archivos de Excel para la gestión de ingresos y rendimiento. La hoja de cálculo de «depósitos de este mes» que mantiene alguien de contabilidad. El registro de «cargos por no presentarse». El libro de trabajo de «pagos pendientes de VCC». A menudo contienen datos de tarjetas pegados desde correos electrónicos, a veces desde hace años.
- Libros de registro escritos a mano. El libro de registro de recepción donde el auditor nocturno anotó: «Cobré el depósito de la Sra. Smith por teléfono, Visa que termina en 4242, cad. 27/06, cobré 400 $». Sí, esto sigue ocurriendo en 2026.
- Portales de proveedores y herramientas de terceros. El CRM que alguien configuró para importar correos electrónicos de OTA tal cual. La bandeja de entrada compartida que el spa utiliza para enviar por correo electrónico números de tarjetas entre el personal. El tablero de Trello que utiliza el departamento de ventas para realizar un seguimiento de los depósitos de contratos. El historial de mensajes directos de Slack con el anterior director de recepción.
El proceso de detección resulta incómodo. La corrección es principalmente administrativa: identificar los datos, clasificarlos (¿son CHD activos o históricos?), destruir o eliminar de forma segura los datos históricos, diseñar los flujos de datos activos para que pasen por el tokenizador y documentar la nueva política que impide que los datos vuelvan a aparecer. Prevea entre tres y diez días-persona para un hotel de 60 habitaciones que haga esto por primera vez. La mayor parte del trabajo consiste en buscar en archivos de correo y destruir copias de seguridad de folios.
El coste real: referencias, no tácticas intimidatorias de los proveedores
El sector de la consultoría PCI tiene un fuerte incentivo para inflar el coste del cumplimiento, ya que así es como venden sus servicios. Los rangos de costes reales, según la vía SAQ y el tamaño del comerciante, están bien documentados y convergen en estos puntos de referencia para un hotel independiente en 2026.
Vía SAQ A (totalmente externalizada, procesador de tokenización, sin CHD electrónico en los sistemas del hotel). Cumplimiento anual del SAQ: menos de 300 $. Escaneos externos trimestrales de un proveedor de escaneo aprobado (ASV): de 500 $ a 2000 $ al año, dependiendo del proveedor. Herramientas de formación anual en concienciación sobre seguridad: de 500 $ a 1000 $. Total: entre 1500 y 3000 dólares al año. Esta es la vía adecuada para la mayoría de los hoteles independientes y es hacia donde debería orientarle el equipo de incorporación de su procesador.
Vía SAQ A-EP (externalización parcial, redireccionamiento del flujo, sin almacenamiento electrónico de CHD, pero la página del hotel puede afectar a la seguridad de las transacciones). Añadir: más preguntas (unas 190 frente a 30), un inventario de scripts documentado y un mecanismo de detección de manipulaciones para los apartados 6.4.3 y 11.6.1, y probablemente un pequeño contrato de consultoría para acertar con la postura del primer año. Total: entre 5000 y 15 000 dólares al año.
Vía SAQ B-IP (terminales IP independientes aprobadas por PTS, sin almacenamiento electrónico de CHD). Total: de 1.500 a 5.000 dólares al año. El proveedor de terminales suele incluir las herramientas de certificación SAQ B-IP en su servicio.
Vía SAQ D (cualquier almacenamiento electrónico de CHD, o cualquier entorno que no se ajuste a un SAQ más específico). SAQ anual: 330 preguntas, a menudo requiere ayuda de consultoría para completarlo correctamente (entre 3.000 y 10.000 dólares el primer año). Escaneos ASV trimestrales: entre 500 y 2.000 dólares. Pruebas de penetración: entre 3.000 y 8.000 dólares al año. Protección de endpoints y revisión básica de registros similar a SIEM: entre 2.000 y 5.000 dólares. Formación anual: entre 500 y 1.500 dólares. Total: entre 15.000 y 50.000 dólares al año para un pequeño comercio independiente. más si se tienen múltiples establecimientos.
Informe de cumplimiento dirigido por un QSA (obligatorio para comerciantes de Nivel 1 con más de 6 millones de transacciones). Total: entre 30 000 y 80 000 dólares solo por la evaluación de un comerciante de tamaño medio, más todos los controles subyacentes. El índice de referencia de ciberseguridad de Hotel Tech Insight 2026 para un hotel independiente de 60 habitaciones sitúa el coste total de la defensa entre 3.500 y 5.000 € el primer año y entre 2.000 y 3.500 € a partir de entonces, lo que se ajusta a la ruta SAQ A anterior más los controles básicos de terminales y de red.
Y por otro lado, vale la pena recordar el índice de referencia de 2025 publicado por Antravia Advisory: los comerciantes del sector turístico tokenizados y conformes con PCI 4.0 pagaron una comisión de intercambio media del 1,8 %, frente al 2,9 % de los comerciantes no conformes. Las devoluciones cayeron del 1,8 % al 0,6 %, y los costes medios de auditoría se redujeron en dos tercios. Para un hotel de 60 habitaciones con unos ingresos por tarjetas de 2 millones de dólares al año, solo la diferencia en la comisión de intercambio supone un ahorro anual recurrente de 22 000 dólares, lo que equivale a entre diez y quince veces el coste del trabajo de cumplimiento del SAQ A. El cumplimiento no es un impuesto. Es una ventaja competitiva que le reporta un beneficio en el momento del pago.
El plan de 90 días que puede llevar a cabo una sola persona
Si su hotel aún no ha abordado la norma PCI DSS 4.0.1, aquí tiene el plan que le permitirá «superar el SAQ A con una arquitectura documentada» en 90 días. Una sola persona con competencia operativa y acceso razonable al director general y al proveedor de TI puede llevarlo a cabo sin necesidad de consultoría externa. Reserve aproximadamente 8 horas a la semana para la persona asignada durante los 90 días.
Días 1 a 15: Alcance y descubrimiento
Trazá el flujo de datos de tarjetas en papel. ¿Por dónde entra un número de tarjeta en tu entorno (motor de reservas, terminal EMV de recepción, correo electrónico de OTA, teléfono, contrato de ventas para grupos)? ¿A dónde va después (tokenizador, pasarela, PMS, exportación de contabilidad)? ¿Dónde se almacena, si es que se almacena en algún sitio (no debería estar en ningún sitio)? A continuación, ejecutá la lista de verificación de los siete lugares donde se ocultan los datos de tarjetas de la sección anterior. Documente todo lo que encuentre en una única hoja de cálculo con tres columnas: ubicación, clasificación (activo o histórico) y corrección prevista. Redacte la política que prohíba explícitamente cada posible incidente futuro («el personal no puede aceptar datos de VCC en texto plano por correo electrónico. las OTA deben utilizar la extranet segura»). Esta fase genera tres resultados: un diagrama de flujo de datos de tarjetas, un registro de descubrimiento y una política escrita sobre el manejo de CHD.
Días 16 a 45: Reducir el alcance a SAQ A
Para cada flujo de datos de tarjetas activo que pase por un sistema del hotel, rediseñalo para que utilice el tokenizador. Si tu motor de reservas muestra el formulario de pago en tu dominio, cambia a la página de pago alojada en un iframe del procesador (la mayoría de los procesadores ofrecen ambas opciones. pregunta). Si su recepción toma los números de tarjeta por teléfono y los introduce en un terminal virtual, asegúrese de que dicho terminal virtual esté alojado por el procesador y no por el hotel. Si su equipo de ventas para grupos acepta datos de VCC por correo electrónico, cambie el cobro de depósitos al producto de enlace seguro del procesador. Destruya los datos históricos de tarjetas descubiertos en la Fase 1 (los en papel a la papelera de la trituradora bajo llave, los electrónicos mediante supresión segura con registro de auditoría). Al final de esta fase, su diagrama de flujo de datos de tarjetas debería mostrar que todos los números de tarjeta entran y salen del entorno del procesador sin pasar nunca por un sistema propiedad del hotel. Esa es la arquitectura que le permite presentar un SAQ A.
Días 46 a 75: Implemente los controles que el SAQ A aún requiere
El SAQ A es breve, pero no está vacío. Los 30 controles abarcan la gestión del acceso del personal, la gestión de proveedores de sus TPSP, la formación en concienciación sobre seguridad y (según la actualización de enero de 2025 de la v4.0.1) la certificación de e-skimming. Haga lo siguiente: habilite la autenticación multifactorial (MFA) en todas las cuentas en la nube que interactúen con el motor de reservas, la pasarela de pago o el PMS. Documente los TPSP que utiliza, recupere su Certificado de Cumplimiento PCI actual (cada uno debería publicar o compartir el suyo) y guárdelos en una carpeta de gestión de proveedores con recordatorios de renovación anual. Implemente formación en concienciación sobre seguridad específica para cada función (recepción, administración, TI) utilizando una herramienta alojada como KnowBe4, Hoxhunt o un equivalente gratuito. Implemente la detección de manipulación de scripts en la página de reservas (Visualping, Feroot o una configuración personalizada de CSP con monitorización) y redacte el procedimiento de escalado de alertas. Implemente o contrate escaneos ASV trimestrales de sus direcciones IP externas (si tiene alguna. para un hotel totalmente SaaS, esto puede tener un alcance prácticamente nulo).
Días 76 a 90: Presentar el SAQ A y certificar
Rellene el SAQ A v4.0.1 utilizando las plantillas del sitio web del PCI SSC. Haga que el director general o el propietario firmen la Parte 3a de la Declaración de Cumplimiento. Envíe la Declaración de Cumplimiento junto con el informe más reciente de un escaneo ASV superado a su banco adquirente a través del portal que este especifique. Confirme la recepción. Configure recordatorios en el calendario para el próximo SAQ anual, los escaneos ASV trimestrales, la revisión semestral de confirmación del alcance (12.5.2.1 si es un proveedor de servicios. anual en los demás casos), la renovación de la formación específica para cada función y el ciclo de renovación de la AoC de TPSP. Este es el trabajo que hace avanzar su programa sin que nadie tenga que volver a descubrirlo todo de cero al cabo de un año.
Dónde encaja Prostay, de forma breve y sincera
Escribo para Prostay, por lo que esta sección es inevitable, pero seré sincero. Prostay Pay es un procesador de pagos con tokenización diseñado para mantener su hotel dentro del ámbito SAQ A de forma predeterminada. Cuando un huésped paga a través del motor de reservas de Prostay o la recepción procesa una tarjeta a través del TPV de Prostay, el número de la tarjeta en sí nunca pasa por la base de datos del PMS de Prostay. solo lo hace una referencia de token. Esa arquitectura es la que hace posible la vía SAQ A para un hotel independiente que utilice Prostay, y es la misma arquitectura que ofrecen Stripe, Adyen, Mews Payments, Cloudbeds Payments y Profitroom Payments. Elija cualquiera de ellos, incluidas las opciones que no sean de Prostay, y podrá estar en la ruta SAQ A en un plazo de 90 días. Elija un procesador que se integre enviando los números de las tarjetas a su PMS, y estará en la ruta SAQ A-EP o SAQ D, con todos los costes y la complejidad que ello implica.
Las opciones específicas de Prostay que importan para PCI: el motor de reservas utiliza un proceso de pago alojado en un iframe que cumple el criterio SAQ A de que «todos los elementos de la página de pago se originan única y directamente de un TPSP que cumple con PCI DSS». la API nunca devuelve datos PAN a las integraciones. la integración de correo electrónico de la OTA analiza los detalles del VCC dentro del entorno de Prostay y solo muestra la referencia tokenizada a la recepción del hotel. Nada de esto es exclusivo de Prostay. Sin embargo, es más fácil hacerlo bien cuando el motor de reservas, el PMS y el tokenizador comparten un límite de auditoría, lo que constituye el argumento estructural real para elegir una pila de un único proveedor en lugar de un conjunto de los mejores productos de su clase.
Si desea una visión más detallada de cómo Prostay Pay gestiona específicamente la tokenización y la arquitectura PCI SAQ A, la página del producto Prostay Pay lo explica paso a paso. Si está migrando desde un PMS heredado con datos de tarjetas almacenados en la base de datos (lo que, por definición, le sitúa en el ámbito de aplicación de SAQ D), la guía de migración de Prostay PMS cubre el paso de eliminación de datos. Y si desea ayuda para ejecutar el plan de 90 días anterior con nuestro equipo de pagos en una llamada, reserve una demostración y le guiaremos a través del proceso sin intentar venderle un servicio de consultoría de cumplimiento normativo por separado.
Preguntas frecuentes
Las cinco preguntas que más me hacen los hoteleros independientes sobre PCI DSS 4.0.1, respondidas con la norma publicada realmente en lugar del resumen de la prensa especializada.
