Lista de verificación 2026: formulario de registro para eventos conforme a la Ley Federal No. 152-FZ

Lista de verificación práctica del formulario de registro: qué datos recopilar, cómo separar los consentimientos y los accesos, y qué revisar antes del lanzamiento.

El formulario de registro a un evento según la Ley Federal No. 152-FZ a menudo parte de un cuestionario antiguo. Por costumbre se le añaden el nombre, los contactos, la empresa, los datos del pasaporte y la alimentación. Luego se coloca al lado una única casilla general. Pero antes de abrir el registro hay que decidir para qué se necesita cada campo, quién lo verá y cuándo eliminará los datos.

En Aventura empezamos por el recorrido de los datos y las acciones del equipo. Si el registro forma parte de la preparación de una conferencia o foro, vinculamos el formulario, las comunicaciones, el control de acceso y el trabajo de los servicios en un solo plan.

Importante: el artículo describe nuestra práctica organizativa, no una consulta jurídica. El operador de datos personales y su abogado aprueban las bases del tratamiento, los textos de los consentimientos, los plazos, los destinatarios, las notificaciones y el esquema de trabajo concreto.

¿Por dónde empezar la revisión de un formulario conforme a la Ley Federal No. 152-FZ?

En breve: empiece por cinco decisiones: quién es el operador, con qué fines se recopilan los datos, sobre qué base se realiza el tratamiento, a quién se comunican los datos y cuándo se eliminan. Mientras las respuestas no estén fijadas, es pronto para entregar el maqueta al diseñador o a la plataforma. La interfaz no corrige campos innecesarios, fines mezclados ni accesos indefinidos.

Se considera operador a quien determina los fines, la composición de los datos y las acciones con ellos. En un proyecto corporativo, este papel a menudo lo conserva el cliente del evento. La plataforma, el recinto, el servicio de impresión, el call center y el equipo de organización pueden tratar datos por su encargo. Pero los roles dependen del esquema real, no del nombre de la empresa en el contrato.

Antes del formulario, elabore un breve pasaporte del tratamiento:

1. la persona jurídica operadora y el contacto para consultas;
2. cada fin del tratamiento en una línea aparte;
3. los campos sin los cuales no se puede cumplir el fin;
4. la base jurídica elegida;
5. las acciones con los datos, los sistemas y los destinatarios;
6. el plazo de tratamiento y la condición de eliminación;
7. el responsable del acceso, la modificación y la finalización del trabajo.

Como regla general, el operador notifica a Roskomnadzor antes de iniciar el tratamiento. Las excepciones son limitadas y, por lo general, un formulario web habitual no entra en ellas. Se verifican por separado los datos de la notificación, la ubicación de las bases de datos de ciudadanos rusos y la existencia de transferencia transfronteriza.

La política de tratamiento de datos personales debe ser accesible desde la página donde se realiza la recopilación. El texto de la página, los contratos con subcontratistas y la notificación del operador no deben describir procesos distintos. Si en el formulario hay alimentación y traslado, pero en los documentos solo se indica un fin abstracto de «prestación de servicios», el modelo debe revisarse.

Matriz de objetivos y campos mínimos

En resumen: el formulario operativo se construye a partir de las acciones del equipo. Para cada campo, indique el objetivo, la siguiente acción, el rol con acceso y el plazo de uso. Si la respuesta no puede vincularse a una operación concreta, el campo se elimina, se hace voluntario o se traslada a una rama condicional. Una ficha común del participante no significa una única tabla para todos los servicios.

Utilizamos una prueba sencilla: objetivo del campo -> quién lo usa -> en qué momento -> quién tiene acceso -> cuándo se elimina. Ayuda a eliminar la recopilación «por si acaso» y a ver de antemano que distintos ejecutores necesitan distintas partes del registro.

La empresa y el cargo son apropiados para una acreditación B2B, el protocolo o el networking. Para un evento abierto no tienen por qué ser obligatorios. El teléfono es necesario cuando existe un escenario claro de llamada, SMS o comunicación urgente. Si la confirmación y los cambios llegan solo por email, el segundo campo de contacto requiere una justificación aparte.

Para el registro de participantes del evento mantenemos un único registro principal con estados. Los servicios reciben versiones reducidas. El mostrador dispone de los datos de entrada, el catering de la categoría de dieta, el conductor de la ruta de transporte. Los datos sobrantes no entran en estas versiones.

La verificación de un campo conviene llevarla por ficha:

Si no se nombra la acción, es mejor eliminar el campo. Si solo es necesario para una parte del público, utilice un bloque condicional. El registro inicial puede constar de nombre, contacto y categoría de participación. Hotel, traslado, aparcamiento y datos para una instalación de régimen se abren tras elegir el servicio correspondiente.

¿Qué consentimientos conviene separar en la interfaz?

El consentimiento para el tratamiento de datos personales, los mensajes publicitarios y la difusión de datos responden a fines distintos. No se pueden ocultar en las normas del evento ni agrupar en una única casilla obligatoria. Desde el uno de septiembre de dos mil veinticinco, el consentimiento para el tratamiento de datos personales se formaliza por separado de la demás información que se confirma. Cada elección se registra y se verifica de forma independiente.

Para un registro abierto y gratuito a menudo se utiliza el consentimiento como base del tratamiento. En la participación de pago, parte de los datos puede ser necesaria para celebrar o ejecutar un contrato. El formato corporativo cerrado exige su propia verificación de las bases. La frase universal «tratamos todo sobre la base del consentimiento» no sustituye este trabajo.

El formulario electrónico debe permitir demostrar la acción de la persona. Pedimos al equipo que conserve la versión del texto, la fecha y la hora, el identificador del formulario, el registro de inscripción y el resultado de cada elección. La casilla no se marca de antemano. El enlace a la política permanece junto a ella, pero la política en sí no sustituye la voluntad del participante concreto.

En la práctica, la interfaz se puede dividir así:

1. elección obligatoria para el tratamiento principal, si el operador utiliza el consentimiento como base del registro;
2. elección voluntaria separada para la publicidad de futuros eventos y ofertas;
3. decisión separada para la publicación del nombre, el cargo, la empresa, la foto o la ficha del participante;
4. las normas de acceso, la oferta y otros documentos se confirman por separado del consentimiento para el tratamiento.

La negativa a la publicidad no debe bloquear el registro. La carta organizativa confirma la solicitud, comunica la dirección, los cambios de programa o las normas de acceso. El anuncio del siguiente evento y la oferta de un socio corresponden a la finalidad de marketing. Analizamos el límite detallado en el material sobre SMS a los participantes sin spam.

La lista pública de participantes requiere especial atención. Si los datos quedan a disposición de un círculo indeterminado de personas, el operador verifica un consentimiento separado para la difusión: qué información se publica, en qué recursos, con qué finalidad y por qué plazo. Una casilla general de registro no crea esa autorización.

Un registro y distintos accesos del equipo

En breve: los datos de cada participante conviene guardarlos en un único registro maestro gestionado, y mostrar a cada servicio solo su conjunto de trabajo. Así el equipo reduce el número de tablas divergentes y limita el acceso innecesario. Cada rol recibe campos, operaciones y plazos concretos. Una exportación completa «para el comité organizador» casi siempre es más amplia que la tarea de los ejecutores.

En nuestra práctica de eventos corporativos, el formulario atiende la acreditación, los badges, la restauración, el transporte y el alojamiento. Por separado, el equipo gestiona los mensajes y la reportabilidad. El error surge cuando todos los procesos reciben un único archivo CSV con todas las columnas.

El acceso se concede por el plazo del proyecto. La modificación manual conserva el autor, la hora, el valor anterior y el nuevo. La exportación recibe el propietario, la finalidad y la fecha. Tras la actualización del registro maestro, la copia antigua no debe seguir siendo la versión de trabajo.

La negativa a una opción no obligatoria recorre toda la cadena. Si el participante cambió su decisión sobre la publicación de su imagen, el estado debe llegar al equipo de grabación y de redacción. La ruta organizativa de esta negativa se describe con más detalle en el artículo sobre el consentimiento para foto y vídeo.

El patrocinador no recibe automáticamente la base general de registro. El contacto se transmite tras una acción separada y comprensible del participante o en otro modelo aprobado. Para el proyecto se pueden usar indicadores agregados y tarjetas de interés voluntarias. Las variantes están recogidas en el análisis de la comunicación con patrocinadores sin transferir la lista de participantes.

Si le resultan útiles estos esquemas de trabajo para la preparación de eventos, los publicamos en el canal de Telegram de «Aventura». En el artículo continuamos la revisión de los campos sensibles y condicionales.

¿Cuándo el pasaporte, la alimentación y las fotos requieren una verificación aparte?

En breve: el pasaporte, los datos de salud y la imagen no se pueden añadir al formulario por costumbre. Para cada uno de estos campos se necesita un objetivo concreto, un volumen mínimo, un acceso restringido y un plazo de eliminación. Los datos del pasaporte no pertenecen automáticamente a categorías especiales, pero a menudo son excesivos. La salud y la identificación por imagen pueden incluir regímenes legales especiales.

El bloque del pasaporte solo es adecuado cuando sin él no se puede cumplir la tarea establecida: por ejemplo, el requisito de una instalación de régimen restringido, una operación contractual o de transporte. Primero solicite la lista por escrito al recinto o a la parte receptora. A veces, para el acceso basta con el nombre completo en la lista y una verificación visual del documento en la entrada.

Si los campos de documentos son necesarios para un grupo aparte, no los muestre a todos. Restrinja el acceso a los empleados que tramitan el pase. En el sistema de registro de trabajo, a otros roles se les puede dejar el estado aprobado o requiere aclaración, sin los datos originales.

La pregunta sobre la alimentación se formula a través de la acción del equipo. En lugar de pedir que enumeren enfermedades, proponga elegir la categoría de dieta necesaria o describir una condición práctica. Acompañe el campo libre con una petición de no indicar diagnósticos ni datos médicos innecesarios.

Para servir el plato normalmente basta con un ID interno, la categoría, el punto y la hora. Este proceso debe vincularse con el catering del evento y limitar el círculo de acceso.

Una fotografía normal con rostro no se convierte en datos biométricos solo por la imagen en sí. El régimen de biometría surge cuando el operador utiliza la imagen para establecer la identidad. La publicación pública del nombre, el cargo, la empresa o la fotografía sigue siendo una tarea aparte y requiere verificar el régimen de difusión.

Para un evento familiar, el formulario debe separar los datos del niño y del representante legal. El rol del representante y sus facultades se verifican según la situación concreta. No se recopilan copias del acta de nacimiento y del pasaporte sin necesidad. Los datos sobre la salud y el acompañamiento solo están disponibles para quienes realizan esta tarea.

La ciudadanía extranjera por sí sola no crea la necesidad de copiar el pasaporte para una acreditación normal. Para una recopilación ampliada, el organizador igualmente necesita un objetivo aparte y una base confirmada.

Contratistas, plataformas y ubicación de almacenamiento de datos

La transferencia de datos a la sede del evento, a la plataforma de registro, al servicio de envíos, al hotel o al proveedor de transporte también forma parte del tratamiento. El operador describe la finalidad, la composición de los datos y las operaciones. Además, verifica por separado la seguridad, el procedimiento de gestión de incidentes y la eliminación. No basta con la frase «el contratista cumple la Ley Federal No. 152-FZ»: se necesitan un contrato y un esquema real de accesos.

El encargo del tratamiento debe corresponder al flujo real. Si la sede recibe la lista de acceso, no necesita las respuestas del cuestionario ni los indicadores publicitarios. Si el logista necesita un teléfono durante el encuentro, no se le pueden transferir automáticamente los contactos de todos los participantes. Para la logística y los traslados recopilamos de antemano una lista reducida y designamos a un responsable de las actualizaciones.

En el encargo conforme a la parte tercera del artículo sexto de la Ley No. 152-FZ se determina obligatoriamente:

1. la lista de datos personales;
2. la lista de acciones con los datos y las finalidades del tratamiento;
3. la obligación de mantener los datos en secreto;
4. los requisitos de la parte quinta del artículo dieciocho y del artículo dieciocho punto uno;
5. la obligación de proporcionar los documentos que confirmen el cumplimiento de los requisitos;
6. los requisitos de seguridad conforme al artículo diecinueve de la Ley No. 152-FZ;
7. la obligación de notificar al operador los casos indicados en la parte tres punto uno del artículo veintiuno.

Adicionalmente, para el proyecto recomendamos acordar el procedimiento de contratación de subcontratistas, la devolución o eliminación de los datos, el trabajo con las copias de seguridad y la forma de confirmar la destrucción una vez finalizada la tarea. Estas condiciones ayudan a cerrar brechas prácticas, pero no forman parte de la lista literal de la parte tercera del artículo sexto.

Al recopilar datos de ciudadanos rusos a través de internet, se verifica dónde se realizan el registro, la sistematización, la acumulación, el almacenamiento, la actualización y la extracción. La indicación del proveedor «servidor en Rusia» no responde a las preguntas sobre las copias de seguridad, la analítica y el sistema global de gestión de clientes (CRM). Además, hay que verificar por separado el soporte extranjero y los encargados del tratamiento contratados.

La transferencia a una persona extranjera o al territorio de otro Estado requiere una evaluación aparte de la transferencia transfronteriza. El operador verifica al destinatario, las medidas de protección y la notificación a Roskomnadzor antes de iniciar dicha transferencia. La versión vigente de los requisitos y el procedimiento concreto debe confirmarlos el abogado del operador.

Verifique por separado las exportaciones a Excel y CSV. Para cada archivo se necesita un responsable, una ubicación de almacenamiento, una finalidad y un plazo. El chat de trabajo y el portátil personal del gerente no deben convertirse en un archivo permanente de la base de datos. Tras modificar un registro, se cierra la exportación antigua y, una vez finalizada la finalidad, se inicia la eliminación acordada.

¿Cómo comprobar un formulario desde el envío hasta la eliminación?

En resumen: un formulario se considera comprobado tras recorrer el trayecto completo de los datos. La prueba abarca la introducción y la confirmación, las ramas condicionales, la modificación del registro y las exportaciones. Después, el equipo verifica la retirada de decisiones, el cierre de accesos y la eliminación. El mensaje «solicitud recibida» solo confirma el primer paso y no muestra lo que vieron los responsables.

Empiece por un participante habitual:

1. abra el formulario desde el teléfono y recórralo con el teclado;
2. compruebe que el operador y los fines son visibles antes del envío;
3. rellene solo los campos obligatorios básicos;
4. deje vacíos la publicidad, la publicación y el contacto de patrocinio;
5. regístrese sin que se le obligue a tomar decisiones opcionales;
6. reciba una confirmación con la fecha, el lugar y la forma de corregir los datos;
7. asegúrese de que el registro aparece una sola vez en la lista maestra;
8. compare los campos de las listas para acreditaciones y mensajes con la matriz de fines.

Después, recorra las ramas condicionales. Al elegir el traslado solo deben abrirse los campos de transporte. Para el hotel se necesitan las fechas y los parámetros de alojamiento, pero no los datos de la tarjeta bancaria en el formulario general. La estructura de trabajo de una lista hotelera independiente puede contrastarse con el material sobre la rooming list del evento.

Compruebe las excepciones:

• la corrección del nombre antes y después de imprimir la acreditación;
• el cambio del contacto principal;
• el reenvío y el duplicado;
• la cancelación y la restauración de la participación;
• la negativa a la publicidad sin cancelar el registro;
• el cambio de la decisión sobre la publicación;
• el cierre de opciones concretas tras la fecha límite;
• un vuelo erróneo con el estado en revisión, y no una confirmación falsa.

El registro tardío no debe prometer un hotel, un traslado o una alimentación especial ya cerrados. El formulario muestra las opciones disponibles y envía la solicitud dudosa al propietario para su confirmación. La lógica de las fechas de control y las excepciones la hemos recogido en el artículo sobre los registros tardíos en un evento B2B.

Después de la interfaz, compruebe los roles. Inicie sesión con cada cuenta y asegúrese de que los campos sobrantes están ocultos. Exporte las listas para acreditaciones, seguridad, alimentación, traslado y alojamiento. La composición de las columnas debe coincidir con la matriz.

Después, retire una elección opcional y compruebe todas las listas relacionadas.

El escenario final cierra el proyecto. El equipo desactiva los accesos temporales, elimina los registros de prueba y pone en marcha la eliminación o anonimización aprobada. Como regla general, la ley establece plazos para el cese del tratamiento y la destrucción en determinadas situaciones, pero la matriz concreta de conservación no puede sustituirse por la sola frase «hasta la retirada». En el tratamiento automatizado, la destrucción se confirma con un acta y una exportación del registro.

Siete errores antes de lanzar el registro

La mayoría de los problemas los genera la mezcla de procesos. Una sola casilla lo cubre todo, el formulario completo se envía a todos los proveedores, la publicidad acaba en los correos de servicio y nadie asigna el plazo de conservación. Estos errores se ven antes del lanzamiento. Para comprobarlo basta con contrastar la interfaz, los documentos y los contratos, y después hacer un registro de prueba y estudiar las exportaciones.

1. Una sola casilla para todas las decisiones. El tratamiento, la publicidad, la publicación, los socios y las normas de acceso requieren una comprobación por separado.
2. El consentimiento está escondido en el botón. Pulsar «Enviar solicitud» no debe confirmar de forma inadvertida varios documentos y finalidades.
3. Campos obligatorios sin utilidad. La fecha de nacimiento, el sexo, la dirección, el pasaporte, la empresa o el cargo se recogen porque estaban en la plantilla anterior.
4. Responsable del tratamiento poco claro. En el formulario figura la marca del proyecto, la política corresponde a otra persona y la base de datos es accesible para una tercera organización.
5. Una sola exportación para todos. El recinto, la imprenta, el catering, el transporte y el marketing reciben un CSV completo.
6. El contacto organizativo se convierte en publicitario. Tras confirmar el registro, la persona pasa a la lista de envíos de futuras ofertas sin una elección aparte.
7. No hay fin del tratamiento. Los datos permanecen en el CRM, el correo, los chats, las hojas locales, el sistema de control de accesos y las copias de seguridad.

Un truco útil en la aceptación: pida al proveedor que realice tres operaciones reales sobre un registro de prueba. Que modifique un campo, limite la visibilidad para un rol y elimine el registro según el procedimiento aprobado. La demostración mostrará de inmediato las discrepancias entre la arquitectura prometida y la real.

¿Qué comprobar el día del lanzamiento?

En resumen: el día de la apertura del registro, el equipo completa el formulario en el teléfono y con distintos roles. Primero revisa los textos, los campos obligatorios y las selecciones individuales. Después comprueba los accesos, los correos, las exportaciones y el registro de acciones. Tras las correcciones, se repite todo el recorrido desde la primera página hasta la aparición de los datos para los responsables.

Modelo legal y organizativo

• [ ] Se ha identificado al operador y se indica un contacto operativo para las solicitudes.
• [ ] Cada finalidad está vinculada a campos, base legal, destinatarios y plazo.
• [ ] La política es accesible desde la página del formulario y coincide con el proceso.
• [ ] El operador ha verificado la notificación a Roskomnadzor y los datos que contiene.
• [ ] Se han comprobado la ubicación de las bases de datos y la posible transferencia transfronteriza.
• [ ] Los contratos con los encargados del tratamiento describen los datos, las operaciones, la seguridad y la eliminación.

Campos e interfaz

• [ ] Solo han quedado como obligatorios los campos necesarios.
• [ ] Los bloques condicionales se abren únicamente para el grupo correspondiente.
• [ ] El consentimiento para el tratamiento está formalizado por separado y no viene marcado de antemano.
• [ ] La publicidad y la difusión se han separado en decisiones voluntarias independientes.
• [ ] El participante puede enviar el formulario sin las casillas opcionales.
• [ ] El error explica qué corregir y no borra las demás respuestas.
• [ ] Las etiquetas de los campos son visibles, el foco del teclado se distingue y el botón móvil es accesible.

Datos y accesos

• [ ] El registro maestro se crea una sola vez.
• [ ] Acreditación, seguridad, restauración, transporte y hotel reciben sus propios conjuntos de columnas.
• [ ] La exportación completa está restringida y queda registrada.
• [ ] La edición manual conserva el autor, la hora y el cambio.
• [ ] Las exportaciones antiguas dejan de ser operativas tras la actualización.
• [ ] A los roles temporales se les ha asignado una fecha de desactivación.

Comunicaciones y finalización

• [ ] La confirmación contiene la fecha, el lugar, el siguiente paso y el canal de corrección.
• [ ] Los mensajes de servicio no contienen publicidad sin un consentimiento específico.
• [ ] La renuncia a una opción no obligatoria actualiza todas las listas relacionadas.
• [ ] Funciona el canal de solicitudes de cese del tratamiento y de rechazo de la publicidad.
• [ ] Se han designado los responsables de la eliminación en el operador y en los proveedores.
• [ ] Para la destrucción se han previsto un acta y un registro.

Tras el primer grupo de prueba, reúna las observaciones en una sola lista, corrija el formulario y repita todo el recorrido. La comprobación de un campo aislado tras un cambio no sustituye una prueba completa: una nueva obligatoriedad puede romper el escenario móvil, un correo o una rama condicional.

Límites de responsabilidad del organizador

En breve: el equipo del evento diseña un recorrido de datos comprensible y verifica que cada servicio reciba el mínimo necesario. El operador de datos personales toma las decisiones sobre los fines y los medios del tratamiento. Su abogado aprueba las bases legales, los textos de consentimiento, los plazos, las notificaciones y el esquema contractual. Los roles trabajan juntos, pero no se sustituyen entre sí.

En Aventura podemos elaborar un mapa operativo de campos y estados. Incluye los accesos para cada rol, los escenarios de prueba, la transferencia a los proveedores y el cierre de accesos. No presentamos un único texto de consentimiento como solución para cualquier evento. Una conferencia abierta, una reunión cerrada de empleados, un día familiar y un viaje con hotel generan procesos distintos.

El resultado práctico de este trabajo es sencillo: cada campo tiene una razón, cada rol tiene un límite, cada exportación tiene un responsable y los datos tienen un final claro de su ciclo de vida. Después, el operador y el abogado revisan este esquema y aprueban los documentos.

Si necesita vincular el formulario, la sede, las comunicaciones y el trabajo de los proveedores, consulte el formato de organización de un evento corporativo. Incluiremos el registro en el plan general del proyecto y prepararemos el proceso para la revisión conjunta del cliente y su abogado.

Fuentes

• Conceptos básicos: artículo 3 de la Ley Federal No. 152-FZ.
• Principios del tratamiento: artículo 5 de la Ley Federal No. 152-FZ.
• Condiciones del tratamiento y encargo: artículo 6 de la Ley Federal No. 152-FZ.
• Consentimiento del interesado: artículo 9 de la Ley Federal No. 152-FZ.
• Categorías especiales de datos: artículo 10 de la Ley Federal No. 152-FZ.
• Datos autorizados para su difusión: artículo 10.1 de la Ley Federal No. 152-FZ.
• Datos personales biométricos: artículo 11 de la Ley Federal No. 152-FZ.
• Transferencia transfronteriza: artículo 12 de la Ley Federal No. 152-FZ.
• Promoción directa mediante medios de comunicación: artículo 15 de la Ley Federal No. 152-FZ.
• Recopilación de datos y localización: artículo 18 de la Ley Federal No. 152-FZ.
• Política y medidas del operador: artículo 18.1 de la Ley Federal No. 152-FZ.
• Seguridad de los datos personales: artículo 19 de la Ley Federal No. 152-FZ.
• Cese del tratamiento y destrucción: artículo 21 de la Ley Federal No. 152-FZ.
• Notificación a Roskomnadzor: artículo 22 de la Ley Federal No. 152-FZ.
• Publicidad por redes de telecomunicaciones: artículo 18 de la Ley Federal No. 38-FZ.
• Formalización separada del consentimiento: Ley Federal No. 156-FZ de 24.06.2025.
• Confirmación de la destrucción: orden de Roskomnadzor No. 179 de 28.10.2022.
• Formularios de notificación: orden de Roskomnadzor No. 180 de 28.10.2022.