大多數表單生成器從外觀上看起來都很相似。拖放編輯器、發布按鈕、提交後的電子郵件通知。介面中沒有任何東西告訴您數據是否已加密、誰可以訪問它，或者收集後它會去哪裡。
表單生成器中的安全故障在成為問題之前很少可見。它們出現在違規通知、合規審核或用戶想知道其數據發生了什麼情況的請求中。
然而，警告標誌大多數是可以提前看到的，這些標誌存在於文檔中、功能集中以及對特定問題的回答中。本文涵蓋了其中的七個標誌。
本文僅供參考，並不構成法律建議。請諮詢合格的數據保護專業人士以獲得針對您組織的具體指導。
標誌 1：無數據處理協議可用
數據處理協議 (DPA) 是收集數據的組織（控制者）與處理數據的平台（處理者）之間的具有法律約束力的合同。在 GDPR 適用的情況下，當控制者使用第三方處理者時，Article 28 要求在處理者代表控制者處理個人數據之前，必須有一份合規的數據處理協議。
合同必須至少定義：處理的主題和期限、涉及的數據類型和個體類別、控制者對處理者的指示、安全義務、次處理者的披露、處理數據主體權利請求的程序、違規通知時間表，以及合同終止時數據的刪除或返回。
這不是一個勾選框。Article 28(3) 明確規定了每個這些元素。隱私政策不是 DPA。服務條款不是 DPA。DPA 是雙方簽署的單獨雙邊文書。
標誌： 表單生成器的網站上沒有可下載的 DPA。搜索 “DPA” 或 “Data Processing Agreement” 沒有結果，或者重定向到一般的隱私政策。
實際意義： 沒有簽署 DPA 的情況下，使用該平台從歐盟的個人收集個人數據會給您的組織帶來法律風險，而不是平台。在 GDPR 下，控制者（您）承擔主要責任，確保有一份符合 Article 28 的協議。即使沒有發生個人數據洩露，未能擁有符合 Article 28 的處理協議本身就是一個合規問題。
類似的責任原則存在於其他隱私框架下。CCPA/CPRA、巴西的 LGPD 和加拿大的 PIPEDA 都期望組織在與第三方服務提供商合作時使用適當的合同保障，儘管法律機制與 GDPR Article 28 不同。
應注意事項： 可公開獲得、可下載的 DPA，無需企業談判即可簽署。對於受 GDPR 管轄的組織，DPA 還應涉及次處理者，即表單生成器本身依賴於基礎設施、存儲或處理的第三方。供應商的 信任中心 通常是找到此文檔的正確地方。要獲得完整的 GDPR 實施清單，請參見 GDPR Compliance for Online Forms: A Practical Checklist。
標誌 2：第三方腳本在表單頁面上運行而未披露
當用戶打開您的表單時，他們可能不僅僅是與您分享他們的數據。
大多數網絡應用程序，包括表單生成器，都會加載第三方 JavaScript 用於分析、廣告、會話記錄、錯誤監控和 A/B 測試。其中一些腳本在用戶輸入時可以訪問表單字段值。這意味著姓名、電子郵件地址或電話號碼可能在用戶點擊 “提交” 之前就已經離開用戶的設備。
這是有文檔記錄的行為。Radboud 大學、KU Leuven 和洛桑大學的研究人員在 2022 年進行的一項名為 “Leaky Forms: A Study of Email and Password Exfiltration Before Form Submission” 的研究發現，在 100,000 個樣本網站中，有 1,844 個網站在未經用戶同意的情況下通過第三方跟蹤腳本在表單提交之前收集用戶的電子郵件地址。數據在任何提交事件發生之前就被悄悄地抽取出來。
機制很簡單：分析和營銷腳本將事件監聽器附加到輸入字段，並將內容傳輸到遠程收集端點。表單生成器本身可能不打算這樣做，但如果第三方腳本在同一頁面上加載，數據無論如何都會流向它們。
標誌： 表單生成器未記錄哪些第三方腳本在已發布的表單頁面上運行。他們的隱私政策描述了他們自己的數據收集，而不是在您的表單上運行的腳本的收集行為。
實際意義： 如果您的表單加載了第三方分析像素或會話記錄工具，您的用戶輸入的數據可能會在未經同意的情況下傳輸給該第三方。這會影響您的隱私政策準確性、您的 GDPR 合規性（處理的合法依據），以及在醫療環境中，可能影響您的 HIPAA 義務。
應注意事項： 明確記錄已發布表單頁面上加載的腳本。處理敏感數據的平台應能夠準確說明哪些服務接收了表單提交的數據以及以何種形式接收。服務於隔離的第一方域名上且無廣告或分析腳本的表單是最強的解決方案。
標誌 3：加密聲明模糊或缺失
“您的數據是安全的” 是一個營銷聲明。它並不描述技術控制。對於表單數據，兩個具體聲明很重要：
傳輸中的加密 意味著數據在用戶的瀏覽器和服務器之間傳輸時被加密。目前的標準是 TLS 1.2 或更高版本。這在網絡上是廣泛的標準，但應明確說明，並包括協議版本。
靜態加密 意味著存儲的數據，即存放在數據庫中的表單提交數據，是加密的。對於敏感數據，目前的標準是 AES-256。這是平台之間的不同之處。有些平台對靜態提交數據進行加密，而許多平台則不然。一個平台可以在傳輸中擁有出色的加密，但同時以明文形式存儲您的數據。
這一區別很重要，因為威脅模型不同。傳輸中的加密可防止在傳輸過程中被攔截。靜態加密可防止未經授權訪問存儲的數據，這是大多數違規情況下的相關威脅。根據 IBM 的 2025 年數據洩露成本報告，平均違規需要 158 天才能識別，83 天才能控制，總生命周期為 241 天，這是九年來的最低水平，根據 IBM Security。在此期間，存儲的數據是主要的暴露點。
OWASP 的 Top 10 (2025) 將 “加密失敗” 列為 A04 — 其中一個最重要的網絡應用程序安全風險，特別包括 “以明文形式存儲的數據” 作為主要失敗模式。
標誌： 平台的安全文檔使用諸如 “我們使用行業標準安全性” 之類的短語，而未指定加密算法、協議版本或覆蓋範圍。沒有提到 AES-256 或 TLS 1.2+。
實際意義： 模糊的加密聲明不提供可驗證的保證。對於受監管的數據，如醫療、金融、法律，靜態加密經常是合規要求，而不是偏好。HIPAA 的安全規則 (45 CFR § 164.312) 特別將加密作為 “可處理” 的保障措施，這意味著受保實體必須實施它或記錄為什麼等效的替代方案提供相同的保護。
應注意事項： 明確的技術聲明：“提交數據在靜態時使用 AES-256 加密，在傳輸中使用 TLS 1.2+ 加密。” 如果這在公共文檔中找不到，通常在供應商的 信任中心 或安全頁面上，請直接詢問。處理敏感數據的平台應該能夠毫不含糊地回答。要獲得安全堆棧應該是什麼樣子的完整分解，請參見 Data Security for Online Forms: What Every Business Should Know。
標誌 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) 作為一個關鍵的網絡應用程序風險，特別是：“可審計的事件，如登錄、登錄失敗和高價值交易，未被記錄。”
標誌： 平台沒有活動日誌。管理員可以查看提交，但無法查看訪問歷史、導出歷史或共享活動。
實際意義： 您無法回答關於誰訪問了特定提交的問題。如果數據主體根據 GDPR Article 15 行使其訪問權，他們可能會要求有關其個人數據已與之共享的接收者或接收者類別的信息，審核日誌有助於回答這一問題。雖然 Article 15 不要求控制者維護審核日誌，但此類日誌可以顯著幫助證明合規並準確回應訪問請求。
應注意事項： 團隊級別的審核日誌，管理員可訪問，至少記錄：提交訪問事件、導出事件、共享鏈接創建和刪除事件。日誌應保留一段時間，以符合您的合規要求。
標誌 6：醫療用途無 BAA 可用
在美國，任何代表受保實體處理受保健康信息 (PHI) 的組織，包括處理患者接收表單的表單生成器，根據 HIPAA (45 CFR § 160.103) 法律上是業務夥伴。
在任何 PHI 通過第三方工具流動之前，必須簽署業務夥伴協議 (BAA)。BAA 不僅僅是一種形式：它建立了業務夥伴關於 PHI 保護、違規通知時間表和允許的數據使用的義務。沒有它，受保實體對業務夥伴處理 PHI 的 HIPAA 違規行為承擔責任，無論平台的實際安全控制如何。
OCR 一直在執行這一要求。即使在沒有違規的情況下，也已經與使用未經授權的第三方工具處理 PHI 的醫療機構達成和解。違規行為是缺少協議，而不是違規。
有關 HIPAA 要求的具體技術保障措施，表單生成器必須實施以有效簽署 BAA，請參見 what HIPAA actually requires from online form tools。
標誌： 平台不提供 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 指南 · 線上表單的資料安全：每個企業都應該知道的事
