符合 GDPR 的电子签名工具：供应商尽调清单

判断电子签名工具能否支持 GDPR 工作流，关键不在于供应商是否展示“合规”标签，而在于其能否提供与实际服务、区域和配置一致的证据。采购、隐私和法务团队应共同核对处理角色、DPA、子处理者、国际传输、保留、数据主体权利和安全运行。

先绘制完整数据地图

这一环节围绕DPA展开。团队应在启用流程前记录处理目的、个人数据类别、数据控制者或数据处理者、授权人员、系统位置、保留期限和可验证证据，并使用一笔具有代表性的电子签名交易验证预期结果和异常路径。审查范围不应只看签名图像，还要覆盖文件正文、签署人联系方式、邀请与身份认证事件、时间戳、管理员操作、API 或集成副本、支持访问及恢复数据。将实际结果与合同、已批准配置及当前法规要求进行比对。第 1 项控制如果只能得到销售口头说明，应记录为证据缺口；如果产品行为与 DPA 或安全资料不一致，应在上线前澄清并形成书面处理条件。每个缺口都需要风险责任人、截止日期和是否阻断上线的明确决定。新数据区域、身份方法、子处理者、集成、保留设置或产品版本上线后，应重新测试这一控制。保存测试输入、输出、审批人、日期和版本，使后续审计能够区分当前证据与已经失效的截图。

让 DPA 对应实际采购服务

这一环节围绕子处理者展开。团队应在启用流程前记录处理目的、个人数据类别、数据控制者或数据处理者、授权人员、系统位置、保留期限和可验证证据，并使用一笔具有代表性的电子签名交易验证预期结果和异常路径。审查范围不应只看签名图像，还要覆盖文件正文、签署人联系方式、邀请与身份认证事件、时间戳、管理员操作、API 或集成副本、支持访问及恢复数据。将实际结果与合同、已批准配置及当前法规要求进行比对。第 2 项控制如果只能得到销售口头说明，应记录为证据缺口；如果产品行为与 DPA 或安全资料不一致，应在上线前澄清并形成书面处理条件。每个缺口都需要风险责任人、截止日期和是否阻断上线的明确决定。新数据区域、身份方法、子处理者、集成、保留设置或产品版本上线后，应重新测试这一控制。保存测试输入、输出、审批人、日期和版本，使后续审计能够区分当前证据与已经失效的截图。

沿数据流核对每个子处理者

这一环节围绕SCC 与 TIA展开。团队应在启用流程前记录处理目的、个人数据类别、数据控制者或数据处理者、授权人员、系统位置、保留期限和可验证证据，并使用一笔具有代表性的电子签名交易验证预期结果和异常路径。审查范围不应只看签名图像，还要覆盖文件正文、签署人联系方式、邀请与身份认证事件、时间戳、管理员操作、API 或集成副本、支持访问及恢复数据。将实际结果与合同、已批准配置及当前法规要求进行比对。第 3 项控制如果只能得到销售口头说明，应记录为证据缺口；如果产品行为与 DPA 或安全资料不一致，应在上线前澄清并形成书面处理条件。每个缺口都需要风险责任人、截止日期和是否阻断上线的明确决定。新数据区域、身份方法、子处理者、集成、保留设置或产品版本上线后，应重新测试这一控制。保存测试输入、输出、审批人、日期和版本，使后续审计能够区分当前证据与已经失效的截图。

数据驻留不能替代跨境传输判断

这一环节围绕远程访问展开。团队应在启用流程前记录处理目的、个人数据类别、数据控制者或数据处理者、授权人员、系统位置、保留期限和可验证证据，并使用一笔具有代表性的电子签名交易验证预期结果和异常路径。审查范围不应只看签名图像，还要覆盖文件正文、签署人联系方式、邀请与身份认证事件、时间戳、管理员操作、API 或集成副本、支持访问及恢复数据。将实际结果与合同、已批准配置及当前法规要求进行比对。第 4 项控制如果只能得到销售口头说明，应记录为证据缺口；如果产品行为与 DPA 或安全资料不一致，应在上线前澄清并形成书面处理条件。每个缺口都需要风险责任人、截止日期和是否阻断上线的明确决定。新数据区域、身份方法、子处理者、集成、保留设置或产品版本上线后，应重新测试这一控制。保存测试输入、输出、审批人、日期和版本，使后续审计能够区分当前证据与已经失效的截图。

按数据类别测试保留与 DSAR

这一环节围绕保留展开。团队应在启用流程前记录处理目的、个人数据类别、数据控制者或数据处理者、授权人员、系统位置、保留期限和可验证证据，并使用一笔具有代表性的电子签名交易验证预期结果和异常路径。审查范围不应只看签名图像，还要覆盖文件正文、签署人联系方式、邀请与身份认证事件、时间戳、管理员操作、API 或集成副本、支持访问及恢复数据。将实际结果与合同、已批准配置及当前法规要求进行比对。第 5 项控制如果只能得到销售口头说明，应记录为证据缺口；如果产品行为与 DPA 或安全资料不一致，应在上线前澄清并形成书面处理条件。每个缺口都需要风险责任人、截止日期和是否阻断上线的明确决定。新数据区域、身份方法、子处理者、集成、保留设置或产品版本上线后，应重新测试这一控制。保存测试输入、输出、审批人、日期和版本，使后续审计能够区分当前证据与已经失效的截图。

用真实故障场景核查安全证据

这一环节围绕DSAR展开。团队应在启用流程前记录处理目的、个人数据类别、数据控制者或数据处理者、授权人员、系统位置、保留期限和可验证证据，并使用一笔具有代表性的电子签名交易验证预期结果和异常路径。审查范围不应只看签名图像，还要覆盖文件正文、签署人联系方式、邀请与身份认证事件、时间戳、管理员操作、API 或集成副本、支持访问及恢复数据。将实际结果与合同、已批准配置及当前法规要求进行比对。第 6 项控制如果只能得到销售口头说明，应记录为证据缺口；如果产品行为与 DPA 或安全资料不一致，应在上线前澄清并形成书面处理条件。每个缺口都需要风险责任人、截止日期和是否阻断上线的明确决定。新数据区域、身份方法、子处理者、集成、保留设置或产品版本上线后，应重新测试这一控制。保存测试输入、输出、审批人、日期和版本，使后续审计能够区分当前证据与已经失效的截图。

识别采购阶段即可发现的红旗

这一环节围绕安全证据展开。团队应在启用流程前记录处理目的、个人数据类别、数据控制者或数据处理者、授权人员、系统位置、保留期限和可验证证据，并使用一笔具有代表性的电子签名交易验证预期结果和异常路径。审查范围不应只看签名图像，还要覆盖文件正文、签署人联系方式、邀请与身份认证事件、时间戳、管理员操作、API 或集成副本、支持访问及恢复数据。将实际结果与合同、已批准配置及当前法规要求进行比对。第 7 项控制如果只能得到销售口头说明，应记录为证据缺口；如果产品行为与 DPA 或安全资料不一致，应在上线前澄清并形成书面处理条件。每个缺口都需要风险责任人、截止日期和是否阻断上线的明确决定。新数据区域、身份方法、子处理者、集成、保留设置或产品版本上线后，应重新测试这一控制。保存测试输入、输出、审批人、日期和版本，使后续审计能够区分当前证据与已经失效的截图。

把尽调结论写入合同与运行控制

这一环节围绕风险责任人展开。团队应在启用流程前记录处理目的、个人数据类别、数据控制者或数据处理者、授权人员、系统位置、保留期限和可验证证据，并使用一笔具有代表性的电子签名交易验证预期结果和异常路径。审查范围不应只看签名图像，还要覆盖文件正文、签署人联系方式、邀请与身份认证事件、时间戳、管理员操作、API 或集成副本、支持访问及恢复数据。将实际结果与合同、已批准配置及当前法规要求进行比对。第 8 项控制如果只能得到销售口头说明，应记录为证据缺口；如果产品行为与 DPA 或安全资料不一致，应在上线前澄清并形成书面处理条件。每个缺口都需要风险责任人、截止日期和是否阻断上线的明确决定。新数据区域、身份方法、子处理者、集成、保留设置或产品版本上线后，应重新测试这一控制。保存测试输入、输出、审批人、日期和版本，使后续审计能够区分当前证据与已经失效的截图。

使用 owner 指南核对完整法律框架

本页只处理一个实施问题。完整的数据地图、法律依据、处理者、跨境传输、保留、安全和数据主体权利框架，请阅读符合 GDPR 的电子签名 owner 指南。签名等级与法律效力则由独立的eIDAS 电子签名指南承接。法律判断应回到 GDPR 正文，角色分配可参考 EDPB 控制者与处理者指南。

把审查结论转化为受控流程

将上述问题转化为证据请求、上线门槛、责任人和定期复核项目。记录实际采用的数据区域、身份方法、子处理者、传输机制、保留配置和异常路径，不要用供应商级标签替代工作流证据。与 eSign.AI 讨论电子签名工作流。