大多数表单生成器从外观上看都很相似。一个拖放编辑器，一个发布按钮，提交时的电子邮件通知。界面中没有任何内容告诉您数据是否被加密，谁可以访问它，或者收集后它会去哪里。
表单生成器中的安全故障在成为问题之前很少可见。它们出现在违规通知、合规审计或用户希望知道其数据发生了什么的请求中。
然而，警告标志大多是提前可见的——在文档中，在功能集里，以及在特定问题的答案中。本文涵盖了其中的七个。
本文仅供参考，不构成法律建议。请咨询合格的数据保护专业人士，以获得针对您组织的具体指导。
标志 1：没有可用的数据处理协议
数据处理协议（DPA）是收集数据的组织（控制者）与处理数据的平台（处理者）之间具有法律约束力的合同。在 GDPR 适用的情况下，如果控制者使用第三方处理者，Article 28 要求在处理者代表控制者处理个人数据之前，必须有一个合规的数据处理协议。
合同必须至少定义：处理的主题和持续时间，涉及的数据类型和个人类别，控制者对处理者的指示，安全义务，子处理者披露，处理数据主体权利请求的程序，违规通知时间表，以及合同终止时的数据删除或返回。
这不是一个复选框。Article 28(3) 明确规定了这些要素中的每一个。隐私政策不是 DPA。服务条款不是 DPA。DPA 是由双方签署的单独的双边文书。
标志： 表单生成器的网站上没有可下载的 DPA。搜索“DPA”或“数据处理协议”没有结果，或重定向到一般隐私政策。
实际意义： 没有签署的 DPA，使用平台从欧盟的个人收集个人数据会给您的组织带来法律风险——而不是平台。在 GDPR 下，控制者（您）对确保存在符合 Article 28 的协议负有主要责任。未能拥有符合 Article 28 的处理协议本身就是一个合规问题，无论是否发生个人数据泄露。
在其他隐私框架下也存在类似的责任原则。CCPA/CPRA、巴西的 LGPD 和加拿大的 PIPEDA 都期望组织在与第三方服务提供商合作时使用适当的合同保障，尽管法律机制与 GDPR Article 28 不同。
需要寻找的内容： 一个公开可用的、可下载的 DPA，可以在不需要企业谈判的情况下签署。对于 GDPR 下的组织，DPA 还应涉及子处理者——表单生成器本身依赖于基础设施、存储或处理的第三方。供应商的信任中心通常是找到此文档的正确位置。有关完整的 GDPR 实施清单，请参见 GDPR 合规性在线表单：实用清单。
标志 2：第三方脚本在表单页面上运行而未披露
当用户打开您的表单时，他们可能不仅仅与您共享他们的数据。
大多数 Web 应用程序——包括表单生成器——都会加载第三方 JavaScript 用于分析、广告、会话记录、错误监控和 A/B 测试。其中一些脚本在用户输入时可以访问表单字段值。这意味着在用户点击“提交”之前，姓名、电子邮件地址或电话号码可能会离开用户的设备。
这是记录在案的行为。2022 年，拉德堡德大学、KU Leuven 和洛桑大学的研究人员进行的一项研究——题为“泄漏的表单：在表单提交之前的电子邮件和密码外泄研究”——发现，在 100,000 个样本中，有 1,844 个网站通过第三方跟踪脚本在没有用户同意的情况下收集用户电子邮件地址。数据在任何提交事件发生之前被悄悄地外泄。
机制很简单：分析和营销脚本将事件监听器附加到输入字段，并将内容传输到远程收集端点。表单生成器本身可能无意此行为——但如果第三方脚本加载在同一页面上，数据无论如何都会流向它们。
标志： 表单生成器没有记录在已发布的表单页面上运行的第三方脚本。他们的隐私政策描述了他们自己的数据收集，而不是在您的表单上运行的脚本的收集行为。
实际意义： 如果您的表单加载了第三方分析像素或会话记录工具，用户输入的数据可能会在未经同意的情况下传输给该第三方。这会影响您的隐私政策准确性、您的 GDPR 合规性（处理的合法基础），以及在医疗保健环境中，可能影响您的 HIPAA 义务。
需要寻找的内容： 明确记录在已发布的表单页面上加载的脚本。处理敏感数据的平台应该能够准确说明哪些服务接收表单提交的数据以及以何种形式。服务于隔离的、第一方域名上的表单，没有广告或分析脚本，是最强的解决方案。
标志 3：加密声明模糊或缺失
“您的数据是安全的”是一种营销声明。它并不描述技术控制。对于表单数据，有两个特定的声明很重要：
传输中的加密意味着数据在用户的浏览器和服务器之间传输时被加密。当前标准是 TLS 1.2 或更高版本。这在整个网络上是广泛的标准——但应该明确说明协议版本。
静态加密意味着存储的数据——在数据库中存放的表单提交——是加密的。敏感数据的当前标准是 AES-256。这是平台之间的差异所在。有些平台对静态数据进行加密；许多平台则不然。一个平台可以在传输中有出色的加密，但在存储时将您的数据以明文形式存储。
这种区别很重要，因为威胁模型不同。传输中的加密保护传输过程中的拦截。静态加密保护存储数据免受未经授权的访问——这是大多数泄露场景中的相关威胁。根据 IBM 的 2025 年数据泄露成本报告，平均泄露需要 158 天才能识别，83 天才能控制——总生命周期为 241 天，是 IBM 安全部门九年来的最低值。在此期间，存储数据是主要的暴露。
OWASP 的 Top 10 (2025) 将“加密失败”列为 A04——最关键的 Web 应用程序安全风险之一——特别包括“以明文形式存储的数据”作为主要失败模式。
标志： 平台的安全文档使用诸如“我们使用行业标准安全”之类的短语，而没有具体说明加密算法、协议版本或覆盖范围。没有提到 AES-256 或 TLS 1.2+。
实际意义： 模糊的加密声明不提供可验证的保证。对于受监管的数据——医疗、金融、法律——静态加密通常是合规要求，而不是偏好。HIPAA 的安全规则（45 CFR § 164.312）特别将加密作为“可寻址”的保障措施，意味着受保护实体必须实施它，或者记录为什么等效的替代方案提供相同的保护。
需要寻找的内容： 一个明确的技术声明：“提交数据在静态时使用 AES-256 加密，在传输时使用 TLS 1.2+ 加密。”如果在公共文档中找不到——通常在供应商的信任中心或安全页面上——直接询问。处理敏感数据的平台应该毫不含糊地回答。有关安全堆栈应如何构建的完整细分，请参见 在线表单的数据安全：每个企业都应了解的内容。
标志 4：没有可配置的数据保留
平台存储您的提交数据的时间有多长？如果答案是“无限期，除非您手动删除它”，那就是一个问题。
GDPR 的存储限制原则（Article 5(1)(e))要求个人数据“以允许识别数据主体的形式保存的时间不得超过处理个人数据的目的所需的时间。”永远存储表单提交——即使是多年前的——几乎从未符合此要求。
还有一个实际风险：平台持有的数据集越大，它作为泄露目标的价值就越高。三年前的表单提交，仍然在服务器上，仍然面临风险。自动删除减少了这种暴露。
不同的工作流程有不同的合法保留需求：
| 表单类型 | 典型保留考虑 |
|---|---|
| 联系和查询表单 | 活跃跟进的持续时间 |
| 潜在客户生成表单 | 活跃的销售周期 |
| 活动注册 | 活动日期加上任何所需的记录保存期 |
| 医疗保健接收 | 适用法规要求的持续时间（HIPAA 要求受保护记录保存 6 年） |
| 就业申请 | 因管辖区而异，并受当地就业法管辖——在设置保留期之前请咨询您的 DPO 或法律顾问 |
标志： 平台默认无限期存储提交。没有设置可配置自动删除计划。唯一的选项是手动删除。
实际意义： 符合数据保留要求取决于人工操作。自动化政策则不然。依赖员工手动删除旧表单提交的组织最终会错过删除周期——尤其是在员工过渡或高峰期。
需要寻找的内容： 在账户或表单级别可配置的保留期。范围应同时适应短期保留（用于高隐私工作流）和延长保留（用于合规要求的记录保存）。“导出到云存储后立即删除”之类的选项代表隐私关键工作流的最佳实践。
标志 5：没有提交访问的审计日志
当提交被打开时，谁打开了它？什么时候？有人导出过吗？是否通过链接共享过？是否被删除，谁删除的？
在没有审计日志的情况下，这些问题都无法回答。这造成了一个显著的责任缺口——在监管审计、数据主体访问请求或内部调查中变得可见。
HIPAA 的安全规则明确解决了这一问题。审计控制标准（45 CFR § 164.312(b))要求受保护实体“实施硬件、软件和/或程序机制，以记录和检查包含或使用电子受保护健康信息的信息系统中的活动。”记录谁查看了提交，以及何时查看，是此要求的直接实施。
超越医疗保健：GDPR Article 5(2) 确立了责任原则——控制者必须能够“证明合规”数据保护原则。审计日志是该证明的基础组成部分。没有它，“我们没有访问该数据”是一个无法验证的声明。
OWASP 的 Top 10 (2025) 将“安全日志记录和警报失败”（A09）列为关键的 Web 应用程序风险——特别是：“可审计事件，例如登录、登录失败和高价值交易，未被记录。”
标志： 平台没有活动日志。管理员可以查看提交，但无法查看访问历史、导出历史或共享活动。
实际意义： 您无法回答有关谁访问了特定提交的问题。如果数据主体根据 GDPR Article 15 行使其访问权，他们可能会请求有关其个人数据已与之共享的接收者或接收者类别的信息——审计日志有助于回答这个问题。虽然 Article 15 不要求控制者维护审计日志，但此类日志可以显著帮助证明合规性并准确响应访问请求。
需要寻找的内容： 管理员可访问的团队级别审计日志，至少记录：提交访问事件、导出事件、共享链接创建和删除事件。日志应保留一段时间，以符合您的合规要求。
标志 6：没有可用于医疗保健用例的 BAA
在美国，任何代表受保护实体处理受保护健康信息（PHI）的组织——包括处理患者接收表单的表单生成器——在 HIPAA (45 CFR § 160.103) 下被合法地视为商业伙伴。
在任何 PHI 通过第三方工具流动之前，必须签署商业伙伴协议（BAA）。BAA 不仅仅是一种形式：它确立了商业伙伴在 PHI 保护、违规通知时间表和允许的数据使用方面的义务。没有它，受保护实体对商业伙伴处理 PHI 引起的 HIPAA 违规承担责任——无论平台的实际安全控制如何。
OCR 一直在执行这一要求。即使没有发生泄露，医疗保健组织也因使用未经授权的第三方工具处理 PHI 而达成和解。违规是缺少协议，而不是泄露。
有关 HIPAA 要求的具体技术保障措施——表单生成器必须实施这些措施才能有效签署 BAA——请参见 HIPAA 实际上对在线表单工具的要求。
标志： 平台不提供 BAA，或仅在大企业定价层提供 BAA，这对大多数医疗保健组织来说是无法访问的。小型诊所、独立治疗师和医疗保健初创公司在没有合规处理关系的情况下收集 PHI。
实际意义： 使用没有 BAA 的表单生成器收集患者数据——接收表单、同意表单、预约请求、与健康信息相关的保险详细信息——是 HIPAA 违规。这不是一个灰色地带。
需要寻找的内容： 在中端市场计划中提供的 BAA，在启用 HIPAA 模式时自动签署（或摩擦最小）。签署的 BAA 应作为文件交付给账户管理员，以便他们在审计中保留和提供。
标志 7：无法根据请求删除单个提交
GDPR Article 17 确立了删除权。当数据主体请求删除其个人数据时，控制者必须在不无故拖延的情况下并在任何情况下在一个月内遵守——受限于有限的例外（法律义务、公共利益等）。请求适用于特定个人的数据，而不是批量档案。
这产生了一个技术要求：您必须能够识别特定个人的提交并干净地删除它。许多平台使这变得困难。通常可以进行批量删除；按响应者进行的目标搜索和删除则不然。
同样的问题影响主动合规性。如果您的保留政策规定在 90 天后删除，您需要平台在记录级别执行这一点——而不仅仅是提供一个“全部擦除”按钮来清除所有内容。
标志： 提交界面没有按响应者标识符（电子邮件、姓名）搜索。删除仅限于批量。无法识别跨多个表单的特定个人的所有提交。
实际意义： 当用户提交删除请求时——GDPR 赋予他们这样做的权利——履行它变成一个手动、容易出错的过程。如果提交跨越多个表单或时间段，查找和删除所有相关记录变得操作上困难。
需要寻找的内容： 按字段值搜索提交，包括电子邮件地址、姓名或任何识别字段。从提交界面删除单个记录。对于 GDPR 下的组织，能够按响应者运行跨表单查询是有价值的。
清单
在发布任何收集敏感数据的表单之前：
- 平台提供可下载、可签署的 DPA
- 平台记录在已发布的表单页面上运行的第三方脚本
- 静态加密（AES-256）和传输中的加密（TLS 1.2+）明确说明
- 数据保留是可配置的，具有自动删除选项
- 审计日志记录提交访问和导出事件
- 如果收集 PHI，必须在收集任何数据之前签署 BAA
- 可以按响应者查找和删除单个提交
参考文献
- 欧洲议会和理事会，GDPR 第 28 条 — 处理者的义务和 DPA 要求，gdpr-info.eu/art-28-gdpr/
- 欧洲议会和理事会，GDPR 第 15 条 — 数据主体的访问权，gdpr-info.eu/art-15-gdpr/
- 欧洲议会和理事会，GDPR 第 17 条 — 删除权，gdpr-info.eu/art-17-gdpr/
- HHS 民权办公室，45 CFR § 160.103 — 定义（业务伙伴），ecfr.gov
- HHS 民权办公室，45 CFR § 164.312 — 技术保障措施，ecfr.gov
- HHS 民权办公室，业务伙伴合同，hhs.gov
- Acar, G. 等，泄露的表单：提交前电子邮件和密码外泄研究，拉德堡德大学 / KU Leuven / 洛桑大学，发表于 USENIX Security 2023
- OWASP，OWASP Top 10 2025，owasp.org/Top10 · A04 加密失败；A09 安全日志和警报失败
- IBM Security，2025 年数据泄露成本报告，ibm.com/reports/data-breach · 平均泄露生命周期 241 天（158 天识别，83 天控制）
相关阅读：在线表单的 GDPR 合规性：实用清单 · HIPAA 合规在线表单：2026 指南 · 在线表单的数据安全：每个企业都应该知道的事
