修订电子签名报告时应如何处理？
不要修改已签署的文件。说明变更理由并创建新修订，保留上一份已签署版本、其哈希值及验证证据。新版本应重新经过技术批准并签署，同时在操作记录中保存两个版本的关联。
这样既能方便地找到最新报告，又不会让旧副本被悄然删除或冒充新版本。电子签名支持已签署版本的完整性。内容变更后，应启动新的签署流程，而不是将旧签名移到新文件上。
应采用怎样的结构保存修订记录？
简要回答：在固定不变的报告标识下，每个已发布版本都应作为独立且不可修改的对象保存；各版本通过“上一版本”和“替代版本”的关系相互关联。
| 记录 | 需保留的信息 | 技术效果 |
|---|---|---|
| 报告主记录 | 固定不变的系统标识、工单和范围 | 同一任务的各个版本归入同一链条 |
| 已发布版本 | 修订编号、文件哈希值、附件清单、发布时间和状态 | 即使文件名变化，也能核验版本 |
| 变更记录 | 原因、变更字段、申请人和影响评估 | 能够说明为何启动修订 |
| 批准与签名 | 复核人、批准人、签名结果、策略和验证时间 | 每个版本都具备自身的决定与签名证据 |
| 分发 | 收件人、渠道、发送版本和通知结果 | 可跟踪针对旧副本所需的通知 |
ISO/IEC 17020:2026 是现行版本，为检验机构的数据与信息控制增加了新规定。在软件中的对应做法，是不仅保存报告文件，还对生成报告的记录、决定、访问和版本关联实施控制。机构应结合自身范围与过渡计划，另行评估适用要求。
操作记录应记载哪些事件？
简要回答：仅记录“谁在何时修改”还不够。还应同时保存变更前后的内容、理由、受影响版本、权限检查结果，以及操作失败时的错误状态。
- 修订申请的创建、理由及来源记录
- 草稿的创建，以及从上一版本继承的字段
- 字段与附件的变更，以及指向旧值和新值的安全引用
- 技术复核、退回、批准及职责分离检查
- 提交签署文件的哈希值及签署操作结果
- 证书、吊销状态、时间戳及所用验证策略的结果
- 发布、门户可见性、下载和对外分发事件
- 旧版本转为“已有新修订替代”状态的过程
操作记录应包含应用用户、可信时间、事件类型、对象标识、结果和理由。管理员权限不应赋予静默重写历史的能力；需要更正的日志应通过新增更正记录予以说明。涉及个人数据的事件，其访问应受角色和实际需要限制。
如何验证新旧版本的签名？
每个版本都应独立验证。旧版本的签名有效，并不表示该版本仍是当前版本；新版本成为当前版本，也不会使旧签名证据失效。
BTK 说明，安全电子签名能够帮助识别已签署数据事后是否被修改；验证方应检查合格证书、有效或吊销状态以及使用限制。ETSI EN 319 102-1 V1.4.1 规定验证流程，ETSI TS 119 102-2 V1.4.1 则规定验证结果的结构化报告方式。应用程序至少应将结果区分为 有效, 无效 以及 无法确定或证据缺失 三类；不得把服务错误视为成功。
- 匹配所需版本的文件哈希值与签名容器。
- 评估签名完整性、证书链、签署时的状态和使用限制。
- 如存在时间戳及长期验证证据，应进行检查。
- 将结果连同验证时间、策略及其版本、错误说明一起关联到版本记录。
- 通过独立的业务规则确定当前、已被替代、已取消或草稿状态。
时间戳和归档包保护什么？
时间戳有助于证明电子数据在某一时刻之前已经存在，但它本身并不等同于版本管理或归档。为支持未来验证，应共同保留已签署文件、证书链、吊销状态证据、时间戳、验证报告及所采用的策略。
BTK《电子签名使用配置指南》区分了携带验证数据的签名、长期签名和归档电子签名格式。归档策略还应将密码算法或策略过时后的证据更新视为有记录的操作。更新不改变旧报告的内容，而是在现有证据包中增加带有历史记录的新保护证据。
门户和分发流程应如何展示旧版本？
应突出当前修订；旧版本仍应允许授权用户查找，并明确显示“已有新修订替代”的状态。
- 旧 URL 或验证记录不应在未告知用户的情况下下载新文件。
- 向用户显示当前查看的报告标识、修订号、发布日期及是否为当前版本。
- 提供指向当前版本的安全链接；不要向所有人公开敏感的变更理由。
- 如需向收到旧副本的人员发出通知或召回，应按收件人创建任务。
- 分发失败时，不应按已成功发送结案。
有关公开验证页面应展示的字段，可参阅 报告二维码验证页面指南 ，可供参阅。
如何建立权限与个人数据安全机制？
启动修订、修改内容、技术批准、签署、发布和访问历史的权限，应分配给不同角色。KVKK 要求采取技术和管理措施，防止非法访问个人数据并确保数据得到保存；其要求是按业务与数据风险采用适当措施，而非统一套用一种安全模型。
因此，操作记录不应成为任何人都能读取的文件。权限矩阵、强身份验证、访问日志、不可篡改备份、恢复测试和事件调查程序应共同发挥作用。保存期限应依据报告类型、合同、适用法规和数据处理目的确定，不应默认对所有情况统一且无限期保存。
VizyonTech 试点应测试哪些场景？
Vizyon Periyodik 解决方案 的评估应在同一报告系列中，同时测试正常修订和异常场景。成功标准不仅是生成新 PDF，还包括系统能够阻止发布错误版本，以及在证据不完整时阻止结案。
- 尝试原地修改已签署文件；系统应要求创建新修订。
- 在没有变更理由的情况下提交审批；系统应阻止流程继续。
- 在签署前改变文件哈希值；签署操作应被取消。
- 无法获取证书状态时检查验证结果；结果应保持为无法确定。
- 打开旧修订的验证页面；应能看到该版本已非当前版本，以及新版本的链接。
- 对于已分发的旧副本，跟踪通知任务及送达证据。
如需了解更完整的批准和电子签名架构， 定期检验流程数字化指南 也可供参阅。
参考来源
- BTK — 电子签名基本信息 （页面更新日期：2026 年 1 月 16 日；访问日期：2026 年 7 月 24 日）。
- BTK — 电子签名法规及电子签名使用配置指南 （法规与配置页面；访问日期：2026 年 7 月 24 日）。
- ETSI — EN 319 102-1，AdES 签名创建与验证程序 （V1.4.1，2024 年 6 月）。
- ETSI — TS 119 102-2，签名验证报告 （V1.4.1，2023 年 6 月）。
- ISO — ISO/IEC 17020:2026，检验机构要求 （第 3 版：2026 年 3 月；更正版：2026 年 6 月）。
- KVKK — 数据安全义务与个人数据安全指南 （访问日期：2026 年 7 月 24 日）。
所采用的签名格式、修订批准方式、保存期限和通知方法，应在评估报告类型、合同、机构范围和现行法规后确定。