审计现场发现研发合规证据缺失，先别急着解释“我们其实做了”。更稳妥的做法是当场把缺失情形分级、确认审计方要什么证据，再按“记录未留存、记录分散、追溯链断裂”分别组织补充说明与旁证材料。补救的核心是用可追溯的原始记录重建证据链，不补造记录，也不在当场给出认证或法律结论。
要点总览（TL;DR）
- 现场先分级：把缺失拆成关键控制点缺失、一般记录缺失、归集方式不规范三类，再向审计方确认证据类型、覆盖范围与提交时限。
- 原因判断按“先查系统原始记录、再查个人留档、最后才判断确实缺失”的顺序，无法验证的只标注“未取得证据”，不写成“未执行”或“已合规”。
- 补救按情形处理：记录未留存由责任人出具情况说明并附同期旁证；记录分散按审计口径归集为带索引的证据包；追溯链断裂以需求—任务—提交—测试—发布为主线重建并标注断点。
- 补充说明写清事实、成因、影响范围、已采取措施、整改计划与责任人，不补造记录、不倒签时间。
- 补救后请审计方抽样复核追溯链，并把证据留存要求落到工作项状态、评审记录与发布流程中，按季度或版本自查闭环。
审计现场先做什么：症状分级与范围确认
证据缺失在审计现场通常表现为几类具体症状：评审记录找不到、审批留痕不完整、需求变更与任务之间的追溯断链、测试与发布记录缺失。这些症状对应的风险并不相同，现场第一步是把它们拆开，而不是笼统回答“资料还在整理”。
建议按影响程度做三级划分，确定补救优先级：
| 级别 | 典型情形 | 处置优先级 |
|---|---|---|
| 关键控制点缺失 | 需求评审、设计评审、上线审批等关键节点的记录完全无法提供 | 最高，现场优先说明并给出补充时间 |
| 一般记录缺失 | 例会纪要、测试执行记录、缺陷处理记录等辅助材料不全 | 次之，可在补充材料中一并提交 |
| 归集方式不规范 | 记录存在，但分散在多个系统、邮件或个人目录，未按审计口径整理 | 较低，重点是归集与索引 |
分级之后，现场需要向审计方确认三件事：需要哪类证据、覆盖哪个时间段和哪些项目范围、补充材料什么时候提交。这三项确认决定了后续工作量，也避免补充方向偏离审计要求。
沟通口径上，先陈述事实与范围，例如“某项目在某时间段内的评审记录目前未能提供，涉及哪几个节点”，再给出补充计划和时间点。现场不宜承诺“肯定没问题”或“全部都能补齐”，无法兑现的结论会放大后续风险。
缺失原因怎么判断：假设与排除证据
“没找到”不等于“没做”。原因判断直接影响补充说明的写法，也影响审计方对问题性质的认定。可以把原因归为三类假设，逐类验证：
| 原因假设 | 可验证的证据 | 验证顺序 |
|---|---|---|
| 流程未执行 | 工作项状态长期停滞、缺少对应流转记录、无相关会议或评审安排 | 最后判断，需排除前两类 |
| 执行了但未留痕 | 代码提交与合并记录、发布记录、邮件或即时沟通中的评审结论 | 第二顺位 |
| 留痕了但分散 | 多个系统中的工作项、文档、邮件、个人留档 | 第一顺位，先查系统原始记录 |
排查顺序建议是：先查研发管理系统中的原始记录，包括工作项状态变化、评审文档、提交与合并记录；再查个人留档和邮件往来；两类都查不到，才判断为确实缺失。这个顺序能避免把“归集问题”误判为“执行问题”。
判断边界要守住：无法验证的事项只能标注为“未取得证据”，不能写成“未执行”，也不能写成“已合规”。补充说明中的每一句结论都应有对应材料支撑，推测性表述在审计复核时很容易被追问。
按情形补救：补充说明与旁证材料的组织
三类情形对应不同的补救动作，材料组织方式也不同。
记录未留存
由该环节的责任人出具情况说明，写清当时做了什么、为什么没有形成记录、有哪些同期材料可以佐证。旁证优先选择系统自动生成、难以事后修改的记录，例如代码提交记录、构建与发布记录、评审通知邮件。情况说明与旁证一起提交，单独一份说明说服力有限。
记录分散未归集
按审计方确认的时间段和项目范围归集材料，形成证据包。证据包应带来源标注和索引：每条材料标明来自哪个系统、哪个工作项或哪封邮件、对应哪个控制点。索引让审计人员能按控制点逐项核对，减少反复问询。
追溯链断裂
以“需求—任务—提交—测试—发布”为主线重建链路，逐段标注材料来源，断点位置单独说明原因。重建时只使用原始记录，缺哪一段就标哪一段，不用推断填补。
补充说明建议包含六个要素：事实（缺什么、涉及什么范围）、成因（属于哪类原因及依据）、影响范围（涉及哪些项目、时间段、控制点）、已采取措施、整改计划与时间点、责任人。全文用陈述句，避免“应该”“大概”这类表述。
风险边界需要明确：不补造记录，不倒签审批和评审时间；涉及数据修改或系统配置调整的操作，先备份并留存操作记录，确保补救过程本身也可追溯。证据归集和追溯链重建如果发生在研发管理平台内，工作项流转记录、评审文档和状态变更历史可以作为原始材料直接导出，ONES 的工作项与评审记录能力可用于承载这类归集；具体配置方式以实际部署为准。
验证补救效果与防止复发
补充材料提交后，补救是否有效要看两个信号：审计方对补充材料给出确认意见，以及抽样复核时追溯链能否从头走通。可以主动请审计方指定几个样本，按需求到发布的路径逐段核对，提前发现仍然断开的环节。
防复发的第一步是把证据留存要求写清楚：每个研发阶段应留存什么、存在哪里、谁负责。这份清单应纳入评审和发布的检查项，评审时核对记录是否归档，发布前确认审批与测试记录是否齐全。
第二步是定期自查。按季度或按版本抽查证据完整性，抽查范围覆盖关键控制点，发现缺口记录在案并跟踪到闭环。自查结果可以作为管理评审的输入，也能在下一次审计前暴露问题。
第三步是机制承载。证据留存要求落到工作项状态流转、评审记录和发布流程中，让留痕成为流程的默认动作，而不是事后补做的额外工作。平台内的状态变更、评审结论和操作记录本身构成可追溯的原始材料，减少对个人留档的依赖。这样，下一次审计时证据归集的工作量会明显下降，追溯链也更容易保持完整。
常见问题
审计方要求当场给出结论，但证据确实还没找到，怎么回应比较稳妥？
当场可以确认事实和范围，例如说明哪类记录目前未能提供、涉及哪些项目和哪个时间段，同时给出补充材料的提交时间点。结论性判断，比如是否合规、是否构成缺陷，留到材料归集和原因核实之后再回应。承诺“肯定能补齐”或“肯定没问题”会放大后续风险，用可兑现的时间表替代结论更稳妥。
记录分散在邮件、即时沟通和个人目录里，归集时怎么保证审计方认可？
归集的关键是来源可核验和索引清晰。每条材料标明来自哪个系统、哪个工作项或哪封邮件、对应哪个控制点，按审计方确认的时间段和项目范围组织成证据包。优先使用系统自动生成、难以事后修改的记录，例如提交记录、构建发布记录、评审通知邮件。个人留档可以作为补充，但需要说明其形成时间和保存方式。
追溯链断了一段，能不能用后来的记录或说明把中间补上？
不能用事后补做的记录填补断点。正确做法是以需求—任务—提交—测试—发布为主线逐段标注材料来源，缺哪一段就标哪一段，并单独说明断点原因。如果断点处有同期旁证，例如发布记录或评审邮件，可以作为佐证附上，但需要标明它与断点的关系，不用推断性描述替代原始记录。
补救完成后，怎么判断审计方是否接受，后续还需要做什么？
可以看两个信号：审计方对补充材料给出确认意见，以及抽样复核时追溯链能否从头走通。主动请审计方指定样本，按需求到发布的路径逐段核对，能提前发现仍然断开的环节。之后把证据留存清单纳入评审和发布检查项，按季度或按版本抽查证据完整性，发现缺口记录在案并跟踪到闭环。
研发管理平台在证据归集和追溯链重建中能起什么作用？
平台内的状态变更、评审结论和操作记录本身构成可追溯的原始材料，可以减少对个人留档的依赖。以 ONES 为例，工作项流转记录、评审文档和状态变更历史可以在权限范围内导出，用于按控制点组织证据包和重建追溯链；具体配置方式和导出范围以实际部署为准。平台承载的是原始记录的归集与呈现，不能替代对缺失事实的说明和整改。
