2026 Checklist: Event Registration Form under Federal Law No. 152-FZ

A practical checklist for your registration form: what data to collect, how to separate consents and access rights, and what to check before launch.

A registration form under Federal Law No. 152-FZ often starts life as an old questionnaire. By habit, it gets a name, contact details, company, passport information and meal preferences added to it. Then a single general checkbox is placed next to it. But before registration opens, you need to decide why each field is needed, who will see it and when the data will be deleted.

At Aventura, we start with the data journey and the team's actions. If registration is part of preparing a conference or forum, we link the form, communications, access control and the work of the various services into a single plan.

Important: this article describes our organisational practice, not legal advice. The personal data operator and their lawyer approve the legal grounds for processing, the consent texts, retention periods, recipients, notifications and the specific workflow.

Where should you start when reviewing a form under Federal Law No. 152-FZ?

In short: start with five decisions: who is the operator, for what purposes the data is collected, on what legal basis processing takes place, to whom the information is transferred, and when it is deleted. Until the answers are documented, it is too early to hand the layout to a designer or a platform. The interface will not fix unnecessary fields, mixed purposes and undefined access rights.

The operator is the party that determines the purposes, the composition of the data and the actions taken with it. In a corporate project, this role is often retained by the event client. The platform, venue, printing service, call centre and organising team may process data on its instructions. But the roles depend on the actual arrangement, not on the company name in the contract.

Before building the form, put together a short processing profile:

1. the legal entity acting as operator and a contact for enquiries;
2. each processing purpose on a separate line;
3. the fields without which the purpose cannot be achieved;
4. the chosen legal basis;
5. the actions taken with the data, the systems and the recipients;
6. the processing period and the deletion condition;
7. the person responsible for access, changes and completion of the work.

As a general rule, the operator notifies Roskomnadzor before processing begins. The exceptions are narrow, and an ordinary web form usually does not fall under them. The information in the notification, the location of databases of Russian citizens and the presence of cross-border transfer are checked separately.

The personal data processing policy must be accessible from the page where collection takes place. The text on the page, contracts with contractors and the operator's notification must not describe different processes. If the form includes catering and transfers, but the documents state only an abstract purpose of "provision of services", the model needs to be revised.

Goal matrix and minimum fields

In short: a working form is built around the team's actions. For each field, state the goal, the next action, the role with access, and how long it will be used. If the answer cannot be tied to a specific operation, the field is removed, made optional, or moved into a conditional branch. A shared participant record does not mean one table for all departments.

We use a simple test: field goal -> who uses it -> at what point -> who has access -> when it is deleted. It helps eliminate "just in case" data collection and shows in advance that different teams need different parts of the record.

Company and job title are appropriate for a B2B badge, protocol, or networking. For an open event they do not have to be mandatory. A phone number is needed when there is a clear scenario for a call, SMS, or urgent contact. If confirmations and changes arrive only by email, a second contact field requires separate justification.

For event participant registration we keep one main record with statuses. Departments receive shortened versions. The desk has access to entry data, catering to the meal category, and the driver to the transport route. Excess information does not go into these versions.

It is convenient to review a field using a card:

If no action is named, it is better to remove the field. If it is needed only by part of the audience, use a conditional block. Initial registration can consist of name, contact, and participation category. Hotel, transfer, parking, and data for a restricted-access venue are opened after the relevant service is selected.

Which consents should be separated in the interface?

Consent to personal data processing, advertising messages and data dissemination serve different purposes. They must not be hidden in the event rules or combined into a single mandatory checkbox. From 1 September 2025, consent to personal data processing is formalised separately from other confirmed information. Each choice is recorded and verified independently.

For free open registration, consent is often used as the legal basis for processing. For paid participation, some data may be needed to conclude or perform a contract. A closed corporate format requires its own verification of legal bases. A universal phrase like "we process everything on the basis of consent" does not replace this work.

The electronic form must make it possible to prove the person's action. We ask the team to save the version of the text, the date and time, the form ID, the registration record and the result of each choice. The checkbox is not pre-ticked. The link to the policy remains nearby, but the policy itself does not replace the specific participant's will.

In practice, the interface can be divided as follows:

1. a mandatory choice for the main processing, if the operator uses consent as the basis for registration;
2. a separate voluntary choice for advertising future events and offers;
3. a separate decision for publishing the participant's name, job title, company, photo or profile card;
4. visiting rules, the offer and other documents are confirmed separately from consent to processing.

Refusing advertising must not block registration. A logistical email confirms the application and provides the address, programme changes or entry rules. An announcement of the next event and a partner offer relate to a marketing purpose. We discuss the detailed boundary in the article on SMS to participants without spam.

A public list of participants requires special attention. If the data becomes available to an indefinite circle of persons, the operator verifies a separate consent to dissemination: what information is published, on which resources, for what purpose and for how long. A general registration checkbox does not create such permission.

One record, different team access levels

In short: participant data is best kept in a single managed master record, with each service shown only the working set it needs. This way the team reduces the number of diverging spreadsheets and limits unnecessary access. Each role gets specific fields, operations and a time limit. A full export "for the organizing committee" is almost always broader than what the people doing the work actually need.

In our practice with business events, the form handles accreditation, badges, catering, transport and accommodation. Communications and reporting are managed separately by the team. Problems arise when every process receives a single CSV file with all the columns.

Access is granted for the duration of the project. Manual changes retain the author, time, old and new value. An export gets an owner, purpose and date. After the master record is updated, the old copy must not remain the working version.

An opt-out from an optional choice carries through the entire chain. If a participant changes their decision about image publication, the status must reach the photo and editorial teams. The organizational route for such an opt-out is described in more detail in the article on photo and video consent.

A sponsor does not automatically receive the general registration database. A contact is passed on only after a separate, clear action by the participant or under another approved model. For the project, aggregated metrics and voluntary interest cards can be used. The options are collected in the analysis of sponsor communications without sharing the participant list.

If you find these working event-preparation schemes useful, we publish them in the Aventura Telegram channel. In this article, we continue reviewing sensitive and conditional fields.

When do passport details, dietary requirements and photos need separate checks?

In short: passport details, health information and images should not be added to a form out of habit. Each such field needs a specific purpose, minimal scope, restricted access and a deletion period. Passport details do not automatically fall into special categories, but they are often excessive. Health data and identification by image may involve special legal regimes.

A passport section is appropriate only where the established task cannot be completed without it: for example, a requirement of a restricted-access facility, a contractual or transport operation. First request a written list from the venue or the host party. Sometimes a full name on the list and a visual check of the document at the entrance are enough for access.

If document fields are needed by a separate group, do not show them to everyone. Restrict access to the employees who issue passes. In the working registration system, other roles can be left with the status approved or needs clarification, without the original details.

The dietary question is phrased in terms of what the team needs. Instead of asking people to list illnesses, offer them a choice of the required meal category or ask them to describe a practical condition. Add a request not to specify diagnoses or unnecessary medical information to the free-text field.

To serve a meal, a service ID, category, point and time are usually enough. This process needs to be linked to event catering and access must be restricted.

An ordinary photo of a face does not become biometric data merely because of the image itself. A biometric regime arises when the operator uses the image to establish identity. Publicly displaying a name, job title, company or photograph remains a separate task and requires checking the distribution regime.

For a family event, the form must separate the child's data from that of the legal representative. The representative's role and authority are verified according to the specific situation. Copies of the birth certificate and passport are not collected without necessity. Health and accompaniment information is available only to those performing this task.

Foreign citizenship in itself does not create a need to copy a passport for an ordinary badge. For extended collection, the organiser still needs a separate purpose and a confirmed legal basis.

Contractors, platforms and data storage location

Transferring data to a venue, registration platform, mailing service, hotel or transport contractor is also part of processing. The operator describes the purpose, the scope of information and the operations. It separately verifies security, incident handling procedures and deletion. A single phrase "the contractor complies with Federal Law No. 152-FZ" is not enough: a contract and an actual access map are required.

The data processing instruction must match the actual data flow. If a venue receives an access list, it does not need questionnaire answers or marketing flags. If a logistics coordinator needs a phone number for the duration of the event, the contacts of all participants must not be automatically passed to them. For logistics and transfers, we prepare a reduced list in advance and appoint an owner for updates.

An instruction under Part 3 of Article 6 of Federal Law No. 152-FZ must specify:

1. the list of personal data;
2. the list of actions with the data and the processing purposes;
3. the obligation to keep the data confidential;
4. the requirements of Part 5 of Article 18 and Article 18.1;
5. the obligation to provide documents confirming compliance with the requirements;
6. the security requirements under Article 19 of Federal Law No. 152-FZ;
7. the obligation to notify the operator of the cases specified in Part 3.1 of Article 21.

In addition, for the project we recommend agreeing on the procedure for engaging subcontractors, the return or deletion of data, the handling of backups and the method of confirming destruction after the task is completed. These conditions help close practical gaps, but they are not part of the literal list in Part 3 of Article 6.

When collecting data of Russian citizens via the internet, it is necessary to check where recording, systematisation, accumulation, storage, updating and retrieval take place. A vendor's statement that the "server is in Russia" does not answer questions about backups, analytics and the global customer relationship management (CRM) system. Foreign support and engaged processors must be checked separately.

Transfer to a foreign person or to the territory of another state requires a separate assessment of cross-border transfer. The operator verifies the recipient, the protection measures and the notification to Roskomnadzor before such transfer begins. The current version of the requirements and the specific procedure must be confirmed by the operator's lawyer.

Check Excel and CSV exports separately. Each file needs an owner, a storage location, a purpose and a retention period. A work chat and a manager's personal laptop must not become a permanent archive of the database. After a record is changed, the old export is closed, and once the purpose is fulfilled, the agreed deletion is initiated.

How do you test a form from submission to deletion?

In short: a form is considered tested only after the full data journey. The test covers input and confirmation, conditional branches, record changes and exports. The team then checks withdrawal of consent, access closure and deletion. A "request received" message confirms only the first step and does not show what the staff saw.

Start as an ordinary participant:

1. open the form on a phone and complete it using the keyboard;
2. check that the operator and purposes are visible before submission;
3. fill in only the basic required fields;
4. leave advertising, publication and sponsor contact empty;
5. register without being forced into optional choices;
6. receive a confirmation with the date, venue and a way to correct your data;
7. make sure the record appears in the master list once;
8. compare the fields in the badge and messaging lists with the purposes matrix.

Then go through the conditional branches. Selecting a transfer should open only the transport fields. For a hotel, dates and accommodation details are needed, but not bank card data in the general form. You can check the working structure of a separate hotel list against the material on the event rooming list.

Check the exceptions:

• correcting a name before and after the badge is printed;
• changing the main contact;
• resubmission and duplicate;
• cancellation and restoration of participation;
• opting out of advertising without cancelling registration;
• changing the publication decision;
• closing individual options after the deadline;
• an erroneous flight with the status under review rather than a false confirmation.

Late registration must not promise a hotel, transfer or special meal that is already closed. The form shows the available options, and sends a disputed request to the owner for confirmation. We covered the logic of cut-off dates and exceptions in the article on late registrations for a B2B event.

After the interface, check the roles. Log in under each account and make sure the extra fields are hidden. Export the lists for badges, security, catering, transfer and accommodation. The set of columns must match the matrix.

Then withdraw an optional choice and check all related lists.

The final scenario closes the project. The team disables temporary access, deletes test records and launches the approved deletion or anonymisation. As a general rule, the law sets deadlines for stopping processing and for destruction in certain situations, but the specific retention matrix cannot be replaced with a single phrase "until withdrawal". In automated processing, destruction is confirmed by a report and a log export.

Seven mistakes to avoid before launching registration

Most problems stem from mixing processes. One checkbox covers everything, the full form goes to all contractors, advertising ends up in service emails, and no one sets a retention period. These mistakes are visible before launch. To check, simply compare the interface, documents and contracts, then go through a test registration and review the exports.

1. One checkbox for all decisions. Processing, advertising, publication, partners and attendance rules each require separate consent.
2. Consent hidden in a button. Clicking “Submit request” should not silently confirm several documents and purposes.
3. Mandatory fields with no purpose. Date of birth, gender, address, passport, company or job title are collected simply because they were in the old template.
4. Unclear data controller. The form shows the project brand, the policy names a different entity, and the database is accessible to a third organisation.
5. One export for everyone. The venue, printing, catering, transport and marketing teams all receive the full CSV.
6. Organisational contact becomes marketing. After confirming registration, the person is added to a mailing list for future offers without a separate opt-in.
7. No end to processing. Data remains in the CRM, email, chats, local spreadsheets, access control system and backups.

A useful acceptance technique: ask the contractor to perform three real operations on a test record. Have them change a field, restrict visibility for a role, and delete the record according to the approved scenario. The demonstration will immediately reveal discrepancies between the promised and actual architecture.

What to check on launch day

In short: on the day registration opens, the team goes through the form on a phone and under different roles. First it checks the copy, required fields and individual choices. Then it checks access, emails, exports and the activity log. After fixes, the whole path is repeated from the first page to the data appearing for the staff who use it.

Legal and organisational model

• [ ] The operator is named and a working contact for enquiries is provided.
• [ ] Each purpose is linked to fields, legal basis, recipients and retention period.
• [ ] The policy is available from the form page and matches the process.
• [ ] The Roskomnadzor notification and the details in it have been checked by the operator.
• [ ] The location of databases and any possible cross-border transfer have been checked.
• [ ] Contracts with processors describe the data, operations, security and deletion.

Fields and interface

• [ ] Only the necessary fields remain required.
• [ ] Conditional blocks open only for the relevant group.
• [ ] Consent to processing is given separately and is not pre-ticked.
• [ ] Advertising and distribution are separate, voluntary decisions.
• [ ] A participant can submit the form without the optional checkboxes.
• [ ] An error explains what to fix and does not erase the other answers.
• [ ] Field labels are visible, keyboard focus is noticeable, and the mobile button is accessible.

Data and access

• [ ] The master record is created once.
• [ ] Badges, security, catering, transport and the hotel each receive their own set of columns.
• [ ] The full export is restricted and logged.
• [ ] Manual edits retain the author, time and change.
• [ ] Old exports stop being valid after an update.
• [ ] Temporary roles have a deactivation date.

Communications and completion

• [ ] The confirmation includes the date, venue, next step and a channel for corrections.
• [ ] Service messages contain no advertising without separate consent.
• [ ] Opting out of an optional choice updates all related lists.
• [ ] There is a working channel for requests to stop processing and to opt out of advertising.
• [ ] Owners of deletion are appointed at the operator and at contractors.
• [ ] A certificate and log are provided for destruction.

After the first test group, collect the comments into a single list, fix the form and repeat the whole path. Checking an individual field after a change does not replace a full run-through: a new required field can break the mobile scenario, an email or a conditional branch.

The organizer's scope of responsibility

In short: the event team designs a clear data flow and verifies that each service receives the minimum it needs. The personal data controller makes decisions about the purposes and means of processing. Its lawyer approves the legal bases, consent texts, retention periods, notifications and contractual arrangements. The roles work together but do not replace one another.

At Aventura, we can build an operational map of fields and statuses. It covers access for each role, test scenarios, transfers to contractors and access closure. We do not present a single consent text as a solution for any event. An open conference, a closed employee meeting, a family day and a trip with a hotel stay create different processes.

The practical outcome of this work is simple: every field has a reason, every role has a boundary, every export has an owner, and the data has a clear end to its lifecycle. The controller and the lawyer then review this scheme and approve the documents.

If you need to connect the form, the venue, communications and the work of contractors, explore our approach to organizing a business event. We will include registration in the overall project plan and prepare the process for joint review by the client and its lawyer.

Sources

• Key concepts: Article 3 of Federal Law No. 152-FZ.
• Processing principles: Article 5 of Federal Law No. 152-FZ.
• Processing conditions and instructions: Article 6 of Federal Law No. 152-FZ.
• Consent of the data subject: Article 9 of Federal Law No. 152-FZ.
• Special categories of data: Article 10 of Federal Law No. 152-FZ.
• Data authorised for dissemination: Article 10.1 of Federal Law No. 152-FZ.
• Biometric personal data: Article 11 of Federal Law No. 152-FZ.
• Cross-border transfer: Article 12 of Federal Law No. 152-FZ.
• Direct marketing via communication channels: Article 15 of Federal Law No. 152-FZ.
• Data collection and localisation: Article 18 of Federal Law No. 152-FZ.
• Operator policy and measures: Article 18.1 of Federal Law No. 152-FZ.
• Personal data security: Article 19 of Federal Law No. 152-FZ.
• Termination of processing and destruction: Article 21 of Federal Law No. 152-FZ.
• Notification to Roskomnadzor: Article 22 of Federal Law No. 152-FZ.
• Advertising via telecommunications networks: Article 18 of Federal Law No. 38-FZ.
• Separate consent form: Federal Law No. 156-FZ of 24.06.2025.
• Confirmation of destruction: Roskomnadzor Order No. 179 of 28.10.2022.
• Notification forms: Roskomnadzor Order No. 180 of 28.10.2022.