Una plataforma certificada es imprescindible, pero la seguridad exige algo más
Web y registro, control de acceso y permanencia, app e impresión de acreditaciones deben protegerse bajo un mismo criterio, también cuando la operación está en manos de un proveedor.
La seguridad de un evento no depende de un único software. Depende de una cadena completa de personas, procesos, dispositivos, integraciones y proveedores. Si uno de esos eslabones queda fuera de los controles auditados, el dato deja de estar realmente protegido.
El riesgo que muchas organizaciones todavía no ven
Las grandes organizaciones suelen exigir procesos de homologación, evaluaciones de riesgo, contratos de encargo de tratamiento de datos y evidencias de seguridad para sus sistemas corporativos. Sin embargo, cuando llega el momento de organizar un evento, esas mismas exigencias pueden relajarse por la presión de los plazos, la temporalidad del proyecto o la idea equivocada de que la información manejada es poco sensible.
Un evento puede concentrar, en pocos días, nombres, cargos, empresas, datos de contacto, credenciales de acceso, preferencias, necesidades de accesibilidad o alimentación, itinerarios, reservas, pagos, agendas de reuniones, perfiles profesionales y registros de asistencia. En determinados encuentros, esa información permite conocer quién está presente, con quién se relaciona y en qué momento.
No es una simple lista de invitados: es un conjunto de datos con valor para el fraude, la suplantación de identidad, la obtención de inteligencia empresarial o el «phishing dirigido» (ataques de correo electrónico que usan datos muy precisos para engañar a asistentes concretos).
Por eso resulta incoherente que una compañía proteja con rigor su correo, su CRM o su ERP y, al mismo tiempo, autorice para un evento una solución que no ha pasado una revisión equivalente. El carácter temporal del evento no reduce la responsabilidad ni el impacto de una brecha. Al contrario: la confluencia de varios proveedores, personal eventual y equipos instalados durante pocos días puede ampliar la superficie de ataque.
La seguridad no es una funcionalidad que se activa en la plataforma principal. Es una propiedad que debe mantenerse mientras el dato se recoge, se consulta, se sincroniza, se imprime, se exporta, se conserva y finalmente se elimina.
La plataforma certificada es el punto de partida imprescindible
La primera capa de protección es tecnológica y es irrenunciable. La plataforma de registro, la app o el sistema de control de acceso deben demostrar que gestionan la seguridad de forma estructurada y bajo estándares verificables. Esa certificación es el punto de partida imprescindible. Pero a partir de ahí debe protegerse una segunda capa igualmente decisiva: la empresa que configura, integra, administra y opera esas herramientas.
Una plataforma puede contar con excelentes controles y, aun así, el riesgo reaparece si el proveedor descarga la base de asistentes en un portátil sin cifrar (es decir, sin protección técnica para que nadie pueda leer el disco duro si se pierde el equipo), si comparte archivos por canales no autorizados, concede más permisos de los necesarios, conserva copias locales después del evento, utiliza cuentas genéricas de administrador o no revoca a tiempo el acceso del personal temporal. Ninguna certificación de la plataforma se extiende de forma automática a esas actividades.
También puede ocurrir lo contrario: que la empresa contratada disponga de una certificación, pero que el servicio concreto, la sede, determinados equipos onsite o algún subencargado queden fuera del alcance auditado. De ahí que la pregunta correcta no sea únicamente «¿tienen ISO 27001?», sino «¿qué entidad, procesos, servicios, ubicaciones y sistemas cubre exactamente el certificado que presentan?».
Qué aporta realmente una certificación y por qué tu proveedor debe dominarla
El estándar ISO/IEC 27001:2022 establece los requisitos de un sistema de gestión de seguridad de la información. Su valor no reside en prometer que nunca habrá un incidente, algo que ninguna organización seria puede garantizar, sino en exigir una gestión continua del riesgo: responsabilidades definidas, políticas, controles, formación, tratamiento de vulnerabilidades, gestión de proveedores, respuesta ante incidentes, auditorías y mejora continua.
Otros marcos pueden aportar evidencia adicional según el servicio: un informe SOC 2 (System and Organization Controls 2) para evaluar la capacidad de una organización de servicios; PCI DSS cuando existe tratamiento de datos de tarjetas; ISO 22301 para garantizar que el servicio siga funcionando ante desastres o ISO/IEC 27701 para la gestión de información de privacidad.
Como organizador del evento, no necesitas memorizar estas siglas, pero es vital que tu proveedor tecnológico sí las domine para poder proteger tu operativa adecuadamente.
La Agencia Española de Protección de Datos recuerda que el responsable debe elegir encargados que ofrezcan garantías suficientes y mantiene un deber de diligencia en su selección y supervisión. Externalizar el servicio no externaliza la responsabilidad. Una certificación vigente y emitida por una entidad competente puede ser una evidencia relevante, pero debe complementarse con contrato, medidas concretas, transparencia sobre subencargados y un análisis proporcional al riesgo del evento.
La responsabilidad de quien elige la solución
La elección de tecnología para un evento no es una decisión neutra ni exclusivamente operativa. Quien propone, valida o autoriza una solución interviene en una decisión de riesgo que debe estar alineada con los criterios de seguridad de la organización. La urgencia, el precio o una funcionalidad atractiva pueden influir, pero no deberían justificar que se omita la homologación o que se acepte una plataforma sin garantías suficientes.
En términos jurídicos, la Ley (como el Reglamento General de Protección de Datos o RGPD) es clara: externalizar el servicio no externaliza la responsabilidad. La Agencia Española de Protección de Datos (AEPD) recuerda que quien organiza el evento es el responsable principal y tiene la obligación de usar proveedores que ofrezcan «garantías suficientes”.
No debe confundirse esa responsabilidad corporativa con una presunción automática de responsabilidad legal personal para quien tramitó la compra. Determinar responsabilidades individuales exigiría analizar el cargo, las competencias, las instrucciones recibidas y las circunstancias concretas. Sin embargo, la decisión profesional sí debe ser explicable y estar documentada.
Tras un incidente informático, la organización necesitará reconstruir y justificar qué requisitos se evaluaron para contratar a ese proveedor, qué evidencias se solicitaron, quién aprobó las excepciones y por qué se consideró aceptable el riesgo.
Por ello, quien selecciona o recomienda la solución debe conservar las certificaciones presentadas por el proveedor y su alcance, el cuestionario de seguridad, el mapa de datos, la relación de subencargados y la validación de las áreas de Seguridad, Tecnología, Compras o Protección de Datos que correspondan.
Si la alternativa elegida no cumple un requisito corporativo, la excepción debe elevarse y aprobarse por la autoridad competente; no debería quedar asumida informalmente por el responsable del evento o por el proveedor.
Exigir certificaciones vigentes tanto a la plataforma como a la empresa que presta el servicio también protege a quien toma la decisión. Le permite demostrar que la selección se apoyó en evidencias objetivas, siguió los controles de la organización y no dependió únicamente del precio, de la urgencia o de una promesa comercial.
Responsabilidad no significa culpabilizar a quien también ha sido víctima de un ataque. Significa poder defender la decisión con evidencias. Ante un incidente, «no lo sabíamos», «era más barato» o «siempre lo habíamos hecho así» no sustituyen a una evaluación documentada de las garantías ofrecidas.
La seguridad debe acompañar todo el ciclo del evento
Web y registro: el punto de entrada
El registro es la puerta de entrada de los datos. Debe cifrar la información, proteger sesiones y cuentas administrativas, controlar las integraciones y limitar la captura y conservación a lo estrictamente necesario. Si incorpora pagos, también debe delimitarse con precisión el alcance de PCI DSS.
Control de acceso y permanencia: seguridad en movimiento
Durante el check-in, los datos llegan a tablets, lectores, redes locales y personal temporal. Los códigos QR deben mostrar la mínima información; los equipos y las cuentas han de estar controlados; y cualquier copia offline debe cifrarse y eliminarse después de la sincronización o al cerrar el evento.
App del evento: perfiles, interacciones y nuevas integraciones
La app concentra perfiles, agenda, mensajería e integraciones. Es esencial limitar lo que puede ver cada participante, aplicar privilegios mínimos a los administradores y proteger las API (las conexiones que permiten a la app comunicarse con otros programas y bases de datos). Incluso los cambios urgentes deben quedar autorizados y trazados.
Impresión de acreditaciones: el riesgo físico también cuenta
La acreditación traslada el dato al mundo físico. Deben controlarse las colas de impresión, los archivos temporales, los kioscos, las impresoras y el material descartado; evitar datos innecesarios en la tarjeta o el QR; y borrar copias locales, revocar accesos y retirar los equipos al finalizar.
Tres incidentes que resumen el riesgo
Estos tres casos ilustran riesgos distintos de la cadena sin afirmar que una certificación los habría evitado por sí sola.
Ticketmaster e Inbenta (2018): integraciones de terceros
Un chatbot de Inbenta integrado en la página de pago permitió acceder a datos financieros de clientes de Ticketmaster. El caso, expuso a 9,4 millones de personas en Europa y derivó en una sanción británica. La enseñanza es directa: los componentes de terceros también forman parte del perímetro y deben evaluarse y monitorizarse.
PyeongChang (2018): la disponibilidad también cuenta
El programa malicioso conocido como Olympic Destroyer interrumpió miles de ordenadores durante los Juegos de Invierno de PyeongChang. El incidente mostró que la seguridad de un evento no es solo confidencialidad: también exige que el evento no se detenga ante un ataque, requiriendo procedimientos alternativos probados (ej. protocolos offline).
Live Nation/Ticketmaster (2024): nube de terceros
Un acceso no autorizado a una base de datos alojada en la nube externa afectó a Ticketmaster, hecho que la matriz tuvo que comunicar a los reguladores financieros de EE. UU. (SEC). El caso recuerda que contratar infraestructura externa (nube) no te libera de vigilar quién accede a ella.
Qué debería exigir un proceso serio de contratación
La seguridad debe compararse con el mismo rigor que el precio, la experiencia del asistente o la velocidad de implantación. Antes de adjudicar, conviene solicitar respuestas y evidencias sobre los siguientes puntos a tu proveedor.
Certificado y alcance. Entidad jurídica certificada, versión del estándar, organismo emisor, acreditación, vigencia, sedes, procesos y servicios que cubre su certificación.
Cobertura de la solución. Relación entre el alcance auditado y cada componente real: registro, acceso, permanencia, app, acreditaciones, integraciones y soporte onsite.
Mapa del dato. Qué información se recoge, dónde se aloja, por qué sistemas circula, quién puede acceder y qué transferencias internacionales pueden producirse.
Identidades y privilegios. Uso de contraseñas individuales y MFA (doble factor de autenticación, como el código que te envía el banco al móvil) para el personal del proveedor, mínimo privilegio, revisión de accesos y plazos de baja para personal interno, externo y temporal.
Cifrado y segregación. Protección para que tus datos estén blindados y separados de los de otros clientes y controles sobre copias, exportaciones y entornos de prueba.
Desarrollo y vulnerabilidades. Ciclo de desarrollo seguro, realización de auditorías de código o «pentesting» (simulacros de ataques informáticos para buscar fallos), gestión de hallazgos y control de cambios urgentes.
Subencargados. Listado de terceros que el proveedor usará para dar el servicio, función de cada uno, ubicación y autorización de cambios.
Incidentes. Canal 24/7, responsabilidades, tiempos de respuesta, conservación de evidencias, coordinación con el cliente y criterios para informar a afectados y autoridades.
Continuidad. Protocolos como RTO y RPO (tiempos máximos tolerables de interrupción del servicio), operación offline controlada y procedimientos alternativos para el día del evento.
Operación onsite. Inventario de equipos, cifrado, custodia, gestión de terminales perdidos, archivos locales, colas de impresión y destrucción segura de material.
Retención y cierre. Plazos exactos para la destrucción segura de los datos tras el evento, revocación de accesos y evidencia de cierre postevento.
Derecho de verificación. Disposición del proveedor a entregar informes de auditoría, responder cuestionarios, obligaciones contractuales y gestión de excepciones.
Una respuesta afirmativa en un cuestionario no sustituye a la evidencia. Cuando un requisito no se cumple, la excepción debe quedar identificada, aceptada por quien corresponda y acompañada de controles compensatorios. Los huecos silenciosos son los que más riesgo concentran.
La seguridad no debe ser el punto débil del evento
La comparación entre una solución con certificaciones verificables y otra que no puede aportar evidencia equivalente no debería limitarse al coste inmediato. La segunda puede trasladar al organizador una carga adicional de evaluación, supervisión y riesgo residual que rara vez aparece en el presupuesto.
Un incidente no afecta solo a la tecnología: afecta a la continuidad del evento, a la confianza del asistente, a la reputación de la marca y a la responsabilidad de quienes decidieron la contratación.
La conclusión es sencilla: elegir una plataforma certificada es imprescindible. La protección se completa cuando la empresa que la configura y opera también trabaja bajo controles verificables y cuando el servicio concreto está incluido en el alcance evaluado.
Debe existir una cadena coherente y verificable que proteja el dato desde el primer formulario hasta la última acreditación destruida, incluyendo a todas las personas y terceros que lo manejan.
En Orquidea Technology Group contamos con un sistema de gestión de seguridad de la información certificado conforme a ISO/IEC 27001:2022. Para nosotros, ese compromiso no es un argumento aislado de venta, sino la base para integrar la seguridad en el diseño, la configuración, la operación onsite y el cierre de cada proyecto. Porque en la lucha contra la delincuencia informática no existe el riesgo cero, pero sí existe la obligación de elevar todas las salvaguardas razonables y de poder demostrar que se han aplicado.
Antes de contratar la tecnología de su próximo evento, solicite el alcance real de las certificaciones y revise toda la cadena de tratamiento. OrquideaTech puede ayudarle a diseñar una arquitectura de evento segura, trazable y alineada con las exigencias de su organización.
*Nota de transparencia: En este artículo; su material gráfico ha sido elaborado con la asistencia de Inteligencia Artificial y posteriormente editado, adaptado y validado por el equipo técnico y editorial de OrquideaTech.
