2026年清单：依据第152-FZ号联邦法律的活动的注册表单

注册表单实用检查清单：收集哪些数据、如何区分同意与访问权限，以及上线前需要检查什么。

按 Federal Law No. 152-FZ 设计的活动报名表单，往往是从旧问卷起步的。人们习惯性地在其中加入姓名、联系方式、公司、护照信息和餐饮要求，然后在旁边放一个统一的勾选框。但在开放报名之前，必须确定每个字段为何需要、谁会看到它，以及何时删除数据。

我们 Aventura 从数据流向和团队操作入手。如果报名属于会议或论坛筹备的一部分，我们会将表单、沟通、门禁管理和各服务部门的工作纳入同一份计划。

重要提示：本文介绍的是我们的组织实践，而非法律意见。个人数据运营者及其律师负责确认处理依据、同意文本、期限、接收方、通知以及具体的工作方案。

如何开始依据联邦第152-FZ号法律检查表单？

简而言之：先从五项决定入手：谁是运营者、收集数据用于哪些目的、依据什么进行数据处理、向谁传递信息以及何时删除信息。在这些答案确定之前，不宜将设计稿交给设计师或平台。界面无法纠正多余字段、混杂目的和不确定的访问权限。

运营者是指确定处理目的、数据构成及对其采取操作的一方。在企业项目中，这一角色通常由活动委托方保留。平台、场地、印刷服务、呼叫中心和组织团队可以受其委托处理数据。但角色取决于实际流程，而非合同中的公司名称。

在制作表单之前，先整理一份简短的处理档案：

1. 作为运营者的法人实体及接收问询的联系方式；
2. 每项处理目的单独列一行；
3. 缺少即无法实现目的的字段；
4. 所选定的法律依据；
5. 对数据的操作、系统和接收方；
6. 处理期限及删除条件；
7. 负责访问、修改和终止工作的责任人。

按照一般规则，运营者应在开始处理前通知Roskomnadzor。例外情形范围很窄，普通网页表单通常不属于例外。需单独核查通知中的信息、俄罗斯公民数据库所在地以及是否存在跨境传输。

个人数据处理政策必须可从收集数据的页面访问。页面上的文本、与承包商的合同以及运营者通知不应描述不同的流程。如果表单中包含餐饮和接送，而文件中仅注明“提供服务”这一抽象目的，则需重新审视该模式。

目标与最小字段矩阵

简要说明：工作表单应围绕团队的实际操作来构建。对于每个字段，请说明其目标、后续操作、具有访问权限的角色以及使用期限。如果某个字段的答案无法与具体操作关联，则应删除该字段、将其设为选填，或移入条件分支。统一的参与者卡片并不意味着所有部门共用一张表。

我们采用一个简单的测试：字段目标 -> 谁使用 -> 在什么时点 -> 谁可访问 -> 何时删除。这有助于消除“以防万一”式的收集，并提前发现不同执行者需要记录的不同部分。

公司和职位适用于B2B胸牌、礼宾或社交拓展。对于公开活动，它们不必设为必填。当存在明确的电话、短信或紧急联系场景时，才需要电话号码。如果确认和变更仅通过email发送，则第二个联系字段需要单独说明理由。

对于活动参与者注册，我们维护一条带状态的主记录。各服务部门获得精简版本。前台可访问入场数据，餐饮部门可访问餐食类别，司机可访问交通路线。多余信息不会进入这些版本。

按卡片核对字段较为方便：

如果未指明操作，最好删除该字段。如果仅部分受众需要，请使用条件区块。初次注册可以仅包含姓名、联系方式和参与类别。酒店、接送、停车及管制场所所需数据在选择相应服务后开放。

界面中应拆分哪些同意项？

个人数据处理同意、广告信息同意和数据传播同意解决的是不同任务。不能将它们隐藏在活动规则中，也不能合并为一个必选复选框。自2025年9月1日起，个人数据处理同意须与其他被确认的信息分开办理。每一项选择都需单独记录和核验。

免费公开注册通常以同意作为处理依据。付费参与时，部分数据可能用于订立或履行合同。封闭式企业活动形式需要单独核验依据。笼统的“我们基于同意处理一切”不能替代这项工作。

电子表单必须能够证明当事人的操作。我们要求团队保存文本版本、日期和时间、表单标识、注册记录以及每一项选择的结果。复选框不得预先勾选。政策链接保留在旁，但政策本身不能替代具体参与者的意愿。

实际操作中，界面可以这样拆分：

1. 若运营方以同意作为注册依据，则为主要处理设置必选项；
2. 针对未来活动广告和优惠设置单独的自愿选择；
3. 针对姓名、职务、公司、照片或参与者卡片的发布设置单独决定；
4. 参观规则、要约及其他文件与处理同意分开确认。

拒绝广告不应阻止注册。组织方信函用于确认申请、告知地址、日程变更或入场规则。下一场活动的预告和合作伙伴优惠属于营销目的。详细边界我们在不发送垃圾短信给参与者一文中分析。

公开参与者名单需要特别关注。如果数据对不特定人群开放，运营方须核验单独的传播同意：哪些信息被发布、在哪些资源上、出于什么目的、期限多长。注册时的通用复选框不构成此类许可。

一条记录与团队的不同访问权限

简要说明：参与者的数据最好存储在一个可管理的主记录中，并且只向每个部门展示其工作所需的数据集。这样团队就能减少不一致的表格数量，并限制多余的访问权限。角色获得具体的字段、操作和期限。“给组委会”的完整导出几乎总是比执行人员的任务范围更广。

在我们的商务活动实践中，表单服务于注册审核、胸牌、餐饮、交通和住宿。团队另行管理消息和报告。当所有流程都拿到一个包含所有列的 CSV 文件时，错误就会发生。

访问权限按项目期限授予。手动修改会保留操作人、时间、旧值和新值。导出会记录所有者、用途和日期。主记录更新后，旧副本不应再作为有效版本保留。

对非必选项的拒绝会贯穿整个流程。如果参与者改变了对图像发布的决定，该状态必须传达到拍摄和编辑团队。关于此类拒绝的组织流程，在照片和视频同意一文中作了更详细的说明。

赞助商不会自动获得总注册数据库。联系方式需在参与者单独且明确的操作之后传递，或采用其他经批准的模型。项目可以使用汇总指标和自愿填写的兴趣卡片。相关方案汇总在不传递参与者名单的赞助商沟通分析中。

如果您觉得这类活动筹备的工作方案有用，我们会将其发布在“Aventura”的 Telegram 频道。本文继续检查敏感字段和条件字段。

何时护照、餐饮和照片需要单独审核？

简要说明：护照、健康信息和图像不能习惯性地加入表单。每个此类字段都需要明确的目的、最小范围、受限访问和删除期限。护照信息并不自动属于特殊类别，但往往属于过度收集。健康信息和通过图像进行的身份识别可能涉及特殊的法律监管制度。

护照信息栏仅在无法完成既定任务时才适用：例如，受管控场所的要求、合同或运输操作。请先向场地或接待方索取书面清单。有时，仅需在名单中提供姓名并在入口处出示证件进行目视核验即可。

如果证件字段仅供特定群体使用，请勿向所有人展示。仅限办理通行证的员工访问。在工作登记系统中，可以为其他角色保留已批准或需澄清状态，而不显示原始信息。

关于餐饮的问题应通过团队行动来表述。不要要求列出疾病，而是建议选择所需的餐食类别或描述实际条件。在自由文本字段中，请提示不要填写诊断和多余的医疗信息。

为发放餐食，通常只需服务ID、类别、地点和时间即可。该流程需与活动餐饮服务关联，并限制访问范围。

普通的含面部照片并不会仅因图像本身而成为生物识别数据。当运营者使用图像进行身份识别时，才适用生物识别制度。公开发布姓名、职位、公司或照片仍是一项独立任务，需要核查传播制度。

对于家庭活动，表单应区分儿童和法定代表人的数据。代表人的角色及其权限需根据具体情况进行核实。除非必要，不收集出生证明和护照的复印件。健康信息和陪同信息仅对执行该任务的人员可见。

外国国籍本身并不产生为普通胸牌复印护照的需求。对于扩展收集，组织者仍需有明确的目的和经确认的依据。

承包商、平台与数据存储位置

向场地、注册平台、邮件发送服务、酒店或交通承包商传输数据同样属于处理活动。运营方需说明目的、信息构成和操作内容，并单独核查安全性、事件处理流程和删除机制。仅凭“承包商遵守第152-FZ号法律”一句话并不足够：还需要合同和实际的访问权限方案。

委托处理必须与实际数据流向相符。如果场地收到的是通行名单，其中不需要包含问卷答案和营销标识。如果物流人员仅在会面期间需要电话号码，则不能自动向其提供所有参与者的联系方式。对于物流与接送，我们会提前整理精简名单并指定更新负责人。

根据第152-FZ号法律第六条第3款作出的委托中，必须明确：

1. 个人数据清单；
2. 数据操作清单及处理目的；
3. 对数据保密的义务；
4. 第十八条第5款及第十八条之一的要求；
5. 提供证明合规文件的义务；
6. 第152-FZ号法律第十九条规定的安全要求；
7. 就第二十一条第3款之一所述情形通知运营方的义务。

此外，针对项目我们建议约定分包商的引入程序、数据的返还或删除、备份处理方式，以及任务完成后确认销毁的方法。这些条件有助于弥补实际操作中的缺口，但不属于第六条第3款的字面清单范围。

通过互联网收集俄罗斯公民数据时，需核查记录、系统化、积累、存储、更新和提取在何处进行。供应商标注“服务器在俄罗斯”并不能回答有关备份、分析以及全球客户管理系统（CRM）的问题。还需单独核查境外技术支持和所涉及的处理方。

向外国主体或另一国境内传输数据需要单独进行跨境传输评估。运营方须在传输开始前核查接收方、保护措施并通知Roskomnadzor。具体要求的最新版本和具体程序应由运营方的律师确认。

请单独检查Excel和CSV导出文件。每个文件都需要有负责人、存储位置、用途和期限。工作聊天群和经理的个人笔记本电脑不应成为数据库的长期存档。记录变更后，旧导出文件应关闭；目的达成后，应启动约定的删除程序。

如何从提交到删除全程验证表单？

简要说明：表单只有在数据走完全部流程后才算验证通过。测试覆盖输入与确认、条件分支、记录修改与导出。随后团队检查决策撤回、权限关闭和删除。仅凭“申请已受理”的提示只能确认第一步，无法反映执行人员实际看到的内容。

先从普通参与者开始：

1. 用手机打开表单，并用键盘完成操作；
2. 确认操作员和目标在提交前可见；
3. 只填写基本必填字段；
4. 将广告、公开发布和赞助方联系方式留空；
5. 在不被强制做出非必要选择的情况下完成注册；
6. 收到包含日期、地点和数据更正方式的确认信息；
7. 确认记录在主列表中只出现一次；
8. 将胸牌和消息列表中的字段与目标矩阵进行比对。

然后走一遍条件分支。选择接送服务时，应只显示交通相关字段。酒店住宿需要日期和住宿参数，但不应在通用表单中要求银行卡信息。单独的酒店名单的工作结构可参考活动 rooming list 一文。

检查异常情况：

• 胸牌打印前后修改姓名；
• 更换主要联系人；
• 重复提交与重复记录；
• 取消并恢复参与；
• 拒绝广告但不取消注册；
• 更改公开发布决定；
• 截止日期后关闭个别选项；
• 航班信息有误时状态为 审核中（审核中），而不是错误地显示为已确认。

迟到的注册不应承诺已经关闭的酒店、接送或特殊餐饮。表单显示可用选项，有争议的请求则发送给负责人确认。关于截止日期和例外情况的逻辑，我们已在B2B 活动迟到注册一文中说明。

界面检查之后，检查角色权限。用每个账号登录，确认多余字段已被隐藏。导出用于胸牌、安保、餐饮、接送和住宿的名单。列组成必须与矩阵一致。

然后撤回非必要选择，并检查所有相关列表。

最后的场景用于关闭项目。团队停用临时权限，删除测试记录，并启动已批准的删除或匿名化操作。按照一般规则，法律规定了在特定情况下停止处理和销毁数据的期限，但具体的存储矩阵不能用一句“直到撤回”来代替。在自动处理的情况下，销毁需通过记录和日志导出予以确认。

注册启动前的七个错误

大多数问题源于流程混杂。一个勾选框覆盖所有事项，完整问卷发给所有供应商，广告混入服务邮件，而存储期限无人指定。这些错误在启动前就能发现。检查时只需对照界面、文档和合同，然后走一遍测试报名并查看导出数据。

1. 一个复选框涵盖所有决定。数据处理、广告、发布、合作伙伴和入场规则需要分别勾选确认。
2. 同意隐藏在按钮中。点击“提交申请”不应在不知不觉中确认多份文件和多个目的。
3. 必填字段没有实际用途。出生日期、性别、地址、护照、公司或职位之所以被收集，只是因为旧模板里有。
4. 运营者不明确。表单上是项目品牌，政策指向另一主体，而数据库却对第三方组织开放。
5. 一份导出数据发给所有人。场地、印刷、餐饮、交通和营销都收到完整的 CSV 文件。
6. 组织性联系方式变成营销渠道。确认报名后，用户未经单独选择就进入未来优惠的邮件列表。
7. 没有处理终止机制。数据留在 CRM、邮件、聊天、本地表格、门禁系统和备份中。

验收时一个有用的做法：请执行方在测试记录上完成三项真实操作。让他修改字段、限制某角色的可见性，并按既定方案删除记录。演示会立刻暴露承诺架构与实际架构之间的差异。

启动当天需要检查什么？

简要说明：开放报名当天，团队要在手机上以不同角色填写表单。先核对文本、必填字段和各个单独选项。然后检查访问权限、邮件、导出和操作日志。修正后，从第一页到执行人员看到数据，完整走一遍全流程。

法律与组织模式

• [ ] 已指明运营者，并注明可供联系的有效联系方式。
• [ ] 每项目的均与字段、依据、接收方和期限相对应。
• [ ] 政策可从表单页面访问，且与实际流程一致。
• [ ] 已向 Roskomnadzor 提交通知，且通知内容已由运营者核实。
• [ ] 已核实数据库所在地及可能的跨境传输。
• [ ] 与处理方的合同说明了数据、操作、安全和删除事项。

字段与界面

• [ ] 必填项仅保留必要字段。
• [ ] 条件区块仅对相应群体显示。
• [ ] 处理同意单独设置，且未预先勾选。
• [ ] 广告和传播已列为独立的自愿决定。
• [ ] 参与者可在不勾选非必选项的情况下提交表单。
• [ ] 错误提示说明需要修正什么，且不清除其他回答。
• [ ] 字段标签可见，键盘焦点明显，移动端按钮可操作。

数据与访问权限

• [ ] 主记录仅创建一次。
• [ ] 胸牌、安保、餐饮、交通和酒店各自获得相应的列集合。
• [ ] 完整导出受到限制并记录日志。
• [ ] 手动修改会保存作者、时间和修改内容。
• [ ] 更新后旧导出文件不再作为有效工作版本。
• [ ] 临时角色已设定停用日期。

沟通与完成

• [ ] 确认信息包含日期、地点、下一步和更正渠道。
• [ ] 服务消息在未单独同意的情况下不包含广告。
• [ ] 取消非必选项会更新所有相关列表。
• [ ] 终止处理请求和拒绝广告的渠道可正常使用。
• [ ] 已指定运营者和承包商的删除负责人。
• [ ] 已为销毁规定记录和日志。

第一组测试结束后，将意见汇总成一份清单，修正表单并重新走一遍全流程。修改后仅检查单个字段不能替代完整测试：新的必填项可能破坏移动端流程、邮件或条件分支。

组织者的责任边界

简要说明：活动团队设计清晰的数据流转路径，并核查每个服务环节都获得必要的最低限度信息。个人数据控制者就处理目的和处理方式作出决定。其律师负责确认合法性依据、同意书文本、期限、通知以及合同架构。各角色协同运作，但不会相互替代。

在 Aventura，我们可以梳理出一份包含字段与状态的操作地图。其中包括各角色的访问权限、测试场景、向承包商的移交以及访问权限的关闭。我们不会把一份同意书文本当作适用于任何活动的通用方案。公开会议、闭门员工会议、家庭日和含酒店住宿的出行，会形成不同的流程。

这项工作的实际成果很简单：每个字段都有其存在理由，每个角色都有明确边界，每次数据导出都有负责人，数据也有清晰的生命周期终点。随后，控制者和律师会核查这一方案并批准相关文件。

如果您需要将报名表单、场地、沟通传播和承包商工作衔接起来，请了解商务活动组织的形式。我们会将注册纳入项目总体计划，并准备好相关流程，供客户及其律师共同核查。

资料来源

• 基本概念：联邦法律第152-FZ号第3条。
• 处理原则：联邦法律第152-FZ号第5条。
• 处理条件与委托：联邦法律第152-FZ号第6条。
• 数据主体同意：联邦法律第152-FZ号第9条。
• 特殊类别数据：联邦法律第152-FZ号第10条。
• 允许传播的数据：联邦法律第152-FZ号第10.1条。
• 生物识别个人数据：联邦法律第152-FZ号第11条。
• 跨境传输：联邦法律第152-FZ号第12条。
• 通过通信手段直接推广：联邦法律第152-FZ号第15条。
• 数据收集与本地化：联邦法律第152-FZ号第18条。
• 运营者政策与措施：联邦法律第152-FZ号第18.1条。
• 个人数据安全：联邦法律第152-FZ号第19条。
• 停止处理与销毁：联邦法律第152-FZ号第21条。
• 通知Roskomnadzor：联邦法律第152-FZ号第22条。
• 通过电信网络进行广告宣传：联邦法律第38-FZ号第18条。
• 同意的单独办理：2025年6月24日联邦法律第156-FZ号。
• 销毁确认：Roskomnadzor 2022年10月28日第179号命令。
• 通知表格：Roskomnadzor 2022年10月28日第180号命令。