Un hotel gestiona cada día un volumen de información personal y financiera comparable al de una entidad bancaria de tamaño medio, con una diferencia decisiva: raramente cuenta con la misma infraestructura de seguridad. Pasaporte, tarjeta de crédito, historial de estancias, preferencias, datos de facturación. Todo circula por el motor de reservas, el PMS, el channel manager y, en muchos casos, por hojas de cálculo y correos que nadie ha auditado nunca. El coste medio de una brecha de datos en el sector hotelero alcanzó los 3,86 millones de dólares en 2024, frente a los 3,62 millones de 2023, y un análisis reciente sobre el sector identificó 95.040 vulnerabilidades en empresas hoteleras, de las cuales 14.318 se clasificaron como críticas. La cifra no habla de un riesgo hipotético, sino de un problema real y estructural que crece al mismo ritmo que la digitalización de la experiencia del huésped.
En TNR entendemos la seguridad de los datos como parte del Revenue Management, no como un capítulo aparte de IT. Un motor de reservas comprometido no solo expone al huésped: paraliza la venta directa, dispara la dependencia de OTAs mientras se resuelve la crisis y erosiona en semanas una reputación de marca construida durante años. Marriott International tuvo que llegar a un acuerdo de 52 millones de dólares tras la exposición de 283 millones de registros de huéspedes, incluidos pasaportes y datos de tarjetas, y el ataque a MGM Resorts, originado por ingeniería social, generó más de 100 millones de dólares en daños. Ningún hotel boutique maneja esos volúmenes, pero el mecanismo del daño es idéntico a menor escala: interrupción operativa, pérdida de confianza, coste legal.
El motor de reservas: exigir certificación, no solo compatibilidad
La primera decisión, y la más determinante, se toma antes de firmar con ningún proveedor. Un motor de reservas no es seguro por usar HTTPS o mostrar un candado en el navegador. La certificación que de verdad importa es el cumplimiento de PCI DSS, el estándar que obliga a cualquier sistema que procesa tarjetas a garantizar cifrado del pago, almacenamiento seguro, escaneo de vulnerabilidades y control de accesos, verificado anualmente por un auditor homologado. La diferencia entre un proveedor “compatible con PCI DSS” y uno “certificado PCI DSS” no es semántica: la certificación implica una auditoría externa completa, mientras que la compatibilidad puede quedarse en una declaración propia sin verificación independiente.
Conviene pedir al proveedor, sin excepción, tres cosas antes de integrarlo en la web del hotel. Que el motor tokenice los datos de tarjeta, de forma que el número real de la tarjeta nunca llegue a tocar los sistemas propios del hotel. Que use cifrado TLS actualizado en todo el tráfico entre el navegador del huésped y el motor. Y que aporte su informe SOC 2 Type II más reciente junto con la documentación de cumplimiento GDPR, porque un proveedor que no puede entregar ambos documentos no debería procesar reservas de huéspedes europeos. La responsabilidad no desaparece por delegar el pago en un proveedor externo: un hotel que redirige a sus clientes a una pasarela de pago externa reduce el alcance del cumplimiento normativo, pero no elimina sus propias obligaciones, ya que el TPV de recepción, el punto de venta del restaurante o el centro de llamadas siguen dentro del perímetro que debe auditarse cada año.
Encriptación: proteger el dato en reposo, no solo en tránsito
El error más habitual es asumir que un candado en el navegador equivale a un dato protegido. El propio proveedor lo aclara con crudeza: el cifrado TLS protege el tráfico entre el navegador del huésped y el motor de reservas, pero no protege cómo se almacenan esos datos, quién puede acceder a ellos ni si los servidores subyacentes están actualizados. Son dos problemas distintos que exigen dos soluciones distintas. El cifrado en tránsito impide que alguien intercepte la información mientras viaja. El cifrado en reposo impide que, si un servidor cae en manos equivocadas, la base de datos se lea como un libro abierto.
La arquitectura correcta separa además el flujo de pago del resto del sistema. Cuando la lógica de pago se mezcla con la del motor de reservas o con el CMS, los datos sensibles terminan apareciendo donde no deberían: registros de log, trazas de error, eventos de analítica. El principio que debería regir cualquier integración es sencillo de enunciar y difícil de improvisar sin experiencia técnica: el dato más seguro es el que el sistema propio nunca llega a manejar. Delegar el procesamiento en pasarelas certificadas que trabajan con tokens, y no con números de tarjeta reales, reduce drásticamente tanto el riesgo como el alcance de cualquier auditoría posterior.
Accesos nominativos: trazabilidad como primera línea de defensa
Uno de los puntos ciegos más comunes en hoteles independientes y boutique es el uso de credenciales compartidas. Un único usuario y contraseña para el PMS que utiliza toda la recepción, un acceso genérico al channel manager que nadie ha cambiado desde la implementación. Esta práctica convierte cualquier incidente en un caso imposible de investigar: si algo falla, no hay forma de saber quién entró, cuándo ni qué modificó. Los accesos nominativos, uno por empleado, con permisos ajustados a su función, resuelven ese problema de raíz. La trazabilidad deja de ser un lujo de auditoría interna y pasa a ser la diferencia entre detectar un acceso anómalo en minutos o descubrirlo meses después, cuando ya es tarde.
El dato respalda esta prioridad: el 70% del personal hotelero tiene acceso a sistemas sensibles sin recibir formación regular en ciberseguridad, y el caso de Marriott con la base de datos de Starwood, cuya intrusión comenzó en 2014 y no se detectó hasta 2018, expuso datos de aproximadamente 339 millones de huéspedes por debilidades que incluían, entre otras causas, una visibilidad de red insuficiente y una detección de anomalías deficiente en sistemas distribuidos geográficamente. Cuatro años sin detección no son un fallo puntual: son la consecuencia directa de no saber quién accede a qué. Establecer accesos individuales, revisarlos periódicamente y revocarlos en el mismo día en que un empleado deja el puesto debería ser un protocolo tan automático como cerrar la caja fuerte al final del turno.
Autenticación en dos pasos: la barrera más rentable que existe
Si hay una medida de seguridad con una relación coste-beneficio que ningún hotel debería ignorar, es la autenticación en dos pasos. Los números lo confirman de forma contundente. Microsoft afirma que los usuarios que activan la autenticación multifactor terminan bloqueando el 99,9% de los ataques automatizados, una cifra que se sostiene independientemente del proveedor: cuando Google forzó la activación de la verificación en dos pasos entre 150 millones de usuarios, el resultado fue una caída del 50% en las cuentas comprometidas. Dado que más del 80% de las brechas de seguridad implican credenciales robadas o comprometidas, según el informe de Verizon, la conclusión es prácticamente aritmética: la mayoría de los incidentes que sufre un hotel dependen de un único factor de autenticación que ya debería haber quedado obsoleto.
Aplicarlo no exige presupuesto de gran cadena. Un segundo factor mediante aplicación de autenticación, o mediante llave de seguridad física para los accesos más críticos, cierra la puerta a los ataques de credential stuffing que hoy explotan de forma sistemática los paneles de PMS, channel manager y correo corporativo del sector. La resistencia a implementarlo suele venir de la comodidad de recepción, no de una limitación técnica real. Es una barrera que se configura en una tarde y que reduce el riesgo de por vida del sistema.
Gestores de contraseñas: el eslabón que casi siempre se rompe primero
La autenticación en dos pasos protege el acceso, pero no resuelve el problema anterior: la calidad de la contraseña que la acompaña. Contraseñas reutilizadas entre el PMS, el correo corporativo y el channel manager siguen siendo, con diferencia, el vector de entrada más común en el sector. Herramientas como 1Password permiten generar credenciales únicas y complejas para cada sistema, almacenarlas cifradas y compartir accesos concretos con el equipo sin que nadie tenga que memorizar ni anotar una contraseña en un post-it pegado al monitor de recepción, una imagen que sigue siendo más habitual de lo que el sector querría admitir.
La ventaja añadida de un gestor centralizado es operativa, no solo de seguridad: cuando un empleado cambia de puesto o abandona el hotel, revocar su acceso a cada sistema se convierte en una acción de un clic, no en una ronda de cambios manuales de contraseña que casi nunca se completa a tiempo. En un sector donde la rotación de personal en recepción y reservas es alta, esta capacidad de revocación inmediata es tan relevante como el propio cifrado de las contraseñas almacenadas.
El eslabón humano: antivirus, adjuntos y enlaces que no son lo que parecen
Toda la arquitectura anterior puede venirse abajo por un solo clic en el ordenador equivocado. Un antivirus y una solución antimalware activos en cada equipo del hotel, no solo en el servidor del PMS sino en cada terminal de recepción, reservas y administración, siguen siendo la barrera mínima e innegociable, y sin embargo es la que con más frecuencia se deja caducar o se desactiva por comodidad cuando ralentiza un equipo antiguo. El phishing sigue siendo, con diferencia, la puerta de entrada más utilizada: representó el 16% de las brechas de seguridad analizadas en el último informe de Verizon, con un coste medio de 4,8 millones de dólares por incidente, y el propio sector hotelero ha protagonizado en 2026 uno de los casos más ilustrativos de hasta dónde ha llegado la sofisticación del engaño. Una campaña activa desde abril de ese año, detectada por Microsoft, dirigida contra hoteles de Europa y Asia, hace pasar correos maliciosos por la infraestructura legítima de notificaciones de Calendly, de forma que superan sin problema los tres filtros de autenticación (PF, DKIM y DMARC) en los que confían la mayoría de sistemas corporativos de correo, para instalar después una puerta trasera oculta en los ordenadores de recepción.
Este tipo de ataque desmonta la idea de que basta con desconfiar de remitentes desconocidos. Un correo puede parecer perfectamente legítimo, superar todas las comprobaciones automáticas y proceder, aun así, de un atacante. Por eso el criterio no puede depender solo del filtro técnico: cualquier documento adjunto no solicitado, especialmente si llega con la etiqueta de urgente, factura pendiente o confirmación de reserva sin datos concretos del huésped, debe abrirse con sospecha y, ante la mínima duda, verificarse por otro canal antes de descargarlo. Con los enlaces el hábito que marca la diferencia es simple de aprender y de aplicar todos los días: pasar el cursor sobre el enlace sin hacer clic para comprobar la URL real que aparece en la parte inferior del navegador, fijarse en errores tipográficos sutiles en el dominio, en extensiones poco habituales o en subdominios que imitan a un proveedor conocido, y desconfiar sistemáticamente de cualquier mensaje que presione con plazos ajustados o amenace con la pérdida de un acceso. La suplantación real de identidad, cuando el atacante logra hacerse pasar de forma convincente por una OTA, un proveedor de pagos o incluso un compañero de otro departamento, se detecta mejor por el contexto que por la apariencia: si la petición implica dinero, credenciales o datos de huéspedes y llega por un canal distinto al habitual, la verificación telefónica directa con la persona o la entidad, usando un número ya conocido y no el que figura en el propio correo, sigue siendo la comprobación más fiable que existe.
Cuando el hackeo es del proveedor, ¿qué puede reclamar el hotel?
Aquí aparece la parte que menos se explica y más sorprende a un hotelero cuando ocurre: si el motor de reservas sufre una brecha, la multa del RGPD no llega a nombre del proveedor, llega a nombre del hotel. Bajo el artículo 28 del reglamento, el hotel actúa como responsable del tratamiento y el proveedor del motor como encargado, y aunque ambas figuras pueden ser sancionadas, la autoridad de control dirige la investigación y la sanción principal contra quien decidió los fines y medios del tratamiento, es decir, contra el hotel. El caso Marriott vuelve a ser el ejemplo de referencia: la intrusión se originó en un sistema heredado de Starwood que nunca se auditó correctamente tras la adquisición, y aun así la responsable de acordar 52 millones de dólares con los estados norteamericanos y de asumir una multa de 18,4 millones de libras por parte del regulador británico fue la cadena hotelera, no el proveedor tecnológico cuyo sistema falló.
Esa responsabilidad no se limita a la sanción administrativa, y ahí está el segundo golpe que muchos hoteles no anticipan. Como responsable del tratamiento, el hotel es quien debe notificar la brecha a la autoridad de control en un plazo de 72 horas, quien debe informar directamente a los huéspedes afectados cuando el riesgo lo justifique, y quien queda expuesto a las denuncias individuales o colectivas que esos huéspedes decidan interponer. Cada una de esas denuncias implica un coste que corre por cuenta del hotel desde el primer minuto, con independencia de dónde se haya originado el fallo técnico: honorarios de defensa legal, peritajes forenses para reconstruir qué ocurrió, gestión de la comunicación de crisis y, en el peor de los escenarios, indemnizaciones a los huéspedes que consigan acreditar un daño. El hotel litiga y responde ante el huésped y ante el regulador aunque el origen material de la brecha esté a cientos de kilómetros, en los servidores de un proveedor sobre el que no tiene ningún control operativo directo.
Esto no significa que el proveedor quede impune, significa que el hotel necesita haber construido su capacidad de reclamación antes del incidente, no después. El contrato de encargo de tratamiento que exige el artículo 28 del RGPD es la primera pieza, pero no basta con que exista: debe establecer con precisión las obligaciones de seguridad del proveedor, su deber de notificar cualquier brecha sin dilación indebida y, sobre todo, una cláusula de indemnización explícita que traslade al proveedor la totalidad de las consecuencias económicas de un fallo originado en su propio sistema. Sin esa cláusula, muchos contratos estándar de motores de reservas limitan la responsabilidad del proveedor al importe de las cuotas de servicio ya pagadas, una cifra irrisoria frente al coste real de una notificación masiva a huéspedes, una sanción administrativa o una demanda colectiva. Con esa cláusula bien redactada, el hotel deja de ser quien absorbe en solitario el coste de defenderse: el proveedor asume la obligación de correr con los gastos legales derivados de las denuncias, de compensar al hotel por las indemnizaciones que este deba abonar y de responder frente al regulador por su propia negligencia técnica, de forma que el hotel no quede desprotegido en su defensa frente a las reclamaciones de sus propios huéspedes. La lección para un hotel boutique es la misma que para una cadena global, solo que se decide en una fase mucho más temprana: antes de firmar con un motor de reservas, hay que leer el contrato de tratamiento de datos con el mismo detalle con el que se lee una cláusula de comisión, exigiendo por escrito esa asunción de responsabilidad, porque es exactamente ahí donde se decide quién paga cuando algo falla.
Una decisión de negocio, no un checklist técnico
Ninguna de estas medidas exige un departamento de IT propio ni una inversión fuera del alcance de un hotel independiente. Exige, eso sí, tratar la seguridad de los datos con el mismo rigor que se aplica a la estrategia de distribución o a la política tarifaria. El coste de no hacerlo ya no es solo reputacional. Bajo el RGPD, una brecha de datos puede derivar en multas de hasta el 4% de la facturación global anual, y a esa cifra se suma la notificación obligatoria a los huéspedes afectados, la auditoría forense y, casi siempre, la pérdida silenciosa de reservas directas que migran de nuevo hacia las OTAs mientras el hotel reconstruye la confianza perdida.
Un motor de reservas certificado, datos cifrados tanto en tránsito como en reposo, accesos nominativos con trazabilidad real, autenticación en dos pasos y un gestor de contraseñas centralizado no son cinco proyectos distintos. Son la misma estrategia aplicada en cinco capas, y su ausencia conjunta explica por qué el sector hotelero sigue siendo uno de los objetivos favoritos del cibercrimen.
