ASPICE评估临近时发现证据缺失，处理顺序比补文档的数量更重要。先按过程域和评估范围把缺失分成“记录从未产生”“记录存在但未归档”“记录内容不满足要求”三类，再判断哪些能在评估前补齐、哪些需要如实说明并准备替代证据。本文给出一条从分类、核实到补救、预审的处置路径，适用于研发过程管理范围内的评估准备。
要点总览（TL;DR）
- 评估前发现证据缺失，先按“记录从未产生、记录存在但未归档、记录内容不满足要求”三类拆分，并对照评估范围圈定受影响的项目、阶段与工作产品，形成带优先级的缺失清单。
- 对每条缺失先列原因假设，再用工作产品库、版本记录、评审与测试日志等线索验证，无法证实的条目保留“未确认”，不直接判定为未执行。
- 处置前先冻结评估范围、基线版本与证据清单口径；可补类按原始时间线回溯补齐并保留补录说明、补录人与补录依据，不可补类整理替代证据并形成统一的偏差说明。
- 补录须守住不伪造、不倒签时间的边界，无法合规补齐时停止补录，转入偏差说明流程。
- 补完后以评估视角按过程域做内部预审，检查证据可定位、可追溯、内容达标，并把证据产出嵌入日常流程节点以防复发。
先判断缺的是什么：证据缺失的三种类型与影响范围
发现证据缺失后，第一步是建立一份可处置的清单，把笼统的“缺证据”拆成具体类型，并圈定本次评估真正受影响的流程域与项目范围。没有这份清单就全面补文档，容易把有限时间花在次要项上，也可能在补的过程中改动评估基线。
三类缺失的区分口径
三类缺失的处置难度和合规风险差别很大，判断时按以下口径归类：
| 缺失类型 | 典型表现 | 处置方向 | 风险程度 |
|---|---|---|---|
| 记录从未产生 | 流程节点没有留下任何工作产品，如某阶段评审未形成记录 | 核实是否确实未执行；可回溯补录的按原始时间线补，不可补的整理替代证据 | 高，涉及流程执行事实 |
| 记录存在但未归档 | 记录散落在个人目录、邮件、其他系统或线下文档中 | 收集、归位、建立索引，补充归档说明 | 低，主要是整理工作量 |
| 记录内容不满足要求 | 有记录但缺少必要字段，如评审结论、责任人签署、追溯关系不完整 | 评估能否基于原始记录补充说明；不能改写历史记录本身 | 中，需判断补充说明的边界 |
圈定受影响的项目、阶段与工作产品
对照本次评估的范围声明和适用过程域，逐项确认缺失发生在哪个项目、哪个阶段、哪类工作产品上。重点看是否触及评估关键证据，例如需求追溯关系、评审记录、测试结果与缺陷处理记录。这些条目通常直接支撑过程域的能力判定，优先级高于一般性会议纪要或计划文档。
同时要区分缺失的性质：流程实际没有执行，属于执行问题；流程执行了但记录没有进入受控位置，属于归档问题。两类问题在后续处置中的动作完全不同，清单中应分别标注。完成这一步后，应得到一份按类型和过程域归类的证据缺失清单，每条标注影响范围与紧急度，作为后续核实与处置的输入。
逐条核实原因：是流程没跑、记录没留，还是找错了位置
清单上的“缺失”只是当前检索结果，不能直接等同于“没做”。逐条核实的目的，是把每一条缺失落到可验证的原因上，避免把找不到当成未执行，也避免把确实未执行的条目误判为归档问题而错过处置窗口。
为每条缺失列出原因假设
对清单中的每一条，先写出可能的原因，常见的有四类：流程未执行；执行了但未留痕；留痕在别的系统、邮件或线下；版本或基线取错，查的是错误时间点的记录。原因假设要具体到条目，例如“需求变更评审记录缺失”可以假设为“评审未召开”“评审召开但纪要未归档”“纪要存放在项目邮件组”“查询的是变更前基线”。
用可查证的线索验证假设
每条假设都要找到对应的验证来源，常见线索包括：
- 工作产品库与文档库中的历史版本和上传记录；
- 版本管理系统中的分支、提交与合并记录；
- 代码评审、变更评审的系统记录或邮件往来；
- 测试执行日志、缺陷单流转记录；
- 会议邀请、会议纪要与任务分派记录；
- 上下游工作产品的引用关系，例如设计文档中引用的需求编号。
验证时优先找能相互印证的组合线索。例如某次评审记录缺失，但代码提交记录、缺陷单和后续设计变更都能对应到同一时间窗口，说明评审很可能发生过，问题更可能出在记录归档环节。反之，如果多个来源都找不到对应活动痕迹，才倾向于判断流程未执行。
记录结论状态，保留“未确认”
核实表应为每条缺失记录原因假设、验证证据、核实结论三项，结论状态分为“确认未执行”“确认已执行未归档”“确认记录不完整”“未确认”。无法证实的条目保留“未确认”，不直接下结论，也不在后续处置中按已执行处理。这份核实表是决定补录还是准备偏差说明的直接依据。
按可补与不可补分别处置：评估前的补救步骤
核实完成后进入处置阶段。核心原则是先冻结、再补录，可补的按原始时间线回溯，不可补的整理替代证据并如实说明。处置顺序影响评估时的可信度，边补边改基线会让证据链自相矛盾。
第一步：冻结评估范围、基线版本与证据清单口径
在动手补任何记录之前，先确认本次评估的范围声明、基线版本和证据清单的检索口径，并形成书面记录。冻结的作用是让后续所有补录和说明都指向同一套范围与版本，避免出现补录记录与评估基线不一致的情况。冻结后如需调整范围，应单独记录调整原因和时间。
第二步：可补类按原始时间线回溯补齐
对确认已执行但记录缺失或不完整的条目，按活动实际发生的时间线回溯补齐。补录时保留三项内容：补录说明（说明原记录为何缺失、依据什么材料补录）、补录人、补录依据（如邮件、系统日志、相关评审的引用关系）。补录说明应放在记录附近或统一的补录台账中，使评估时能看清记录的来源。
第三步：不可补类整理替代证据与偏差说明
对确认未执行或无法证实的条目，整理能间接支撑的替代证据，例如上下游工作产品的引用关系、系统操作日志、相关活动的后续处理记录。同时形成偏差说明，写清缺失条目、影响的过程域、已采取的补救措施和当前状态。偏差说明的口径应统一，避免同一类问题在不同条目上给出互相矛盾的解释。
操守边界与停止点
补录过程中有几条边界必须守住：不伪造从未发生的活动记录，不倒签时间，不修改已归档记录的历史内容来制造“当时就有”的假象。补录说明本身就是合规的一部分，它承认记录是后补的，并给出依据。当某条缺失无法在不伪造的前提下补齐时，停止补录动作，转入偏差说明流程。涉及修改历史记录的操作，应先评估对评估结论的影响，并明确由谁批准、在什么条件下执行。
按优先级排序处置
时间有限时，处置顺序建议为：先处理影响评估关键过程的证据，如需求追溯、评审记录、测试结果；再处理支撑性记录，如计划、会议纪要、培训记录；最后处理一般性归档整理。每条处置任务应明确责任人和完成时点，形成分优先级的处置计划。
在证据归位和补录说明的管理上，可以把每条缺失作为工作项跟踪状态，把补录说明与偏差说明放入与项目关联的文档库，使记录可定位、可追溯。ONES 的解决方案中包含项目管理、知识库、测试管理等模块组合，并支持跨域协作全过程的可追溯性，可作为承载证据清单核对与归档流转的一种方式；具体模块与过程域的对应关系需结合团队实际配置确认。
补完之后怎么验证：内部预审与复发预防
处置完成不等于证据链闭合。评估前应以评估视角做一次内部预审，确认每条关键证据可定位、可追溯、内容满足要求，并把仍存在的缺口转化为评估时的说明口径和后续的预防机制。
以评估视角做内部预审
预审按过程域组织，而不是按文档目录组织。每个过程域抽查若干条关键证据，检查三件事：证据能否在受控位置被找到；证据之间的追溯关系是否完整，例如需求到设计、设计到测试、测试到缺陷的链路是否闭合；证据内容是否包含评估关注的信息，如评审结论、责任人、时间与版本。抽查应覆盖本次评估范围内的主要项目和阶段，而不是只看准备得最充分的部分。
设定通过标准并记录残余风险
通过标准可以设为：每条关键证据可定位、可追溯、内容满足要求；补录条目均有补录说明和依据；偏差条目均有偏差说明。未达到标准的条目列入残余风险清单，逐条写明缺口内容、影响的过程域和评估时的说明口径。说明口径应提前统一，由熟悉评估范围的人员确认，避免评估现场临时解释出现分歧。
把证据产出嵌入日常流程节点
本次缺失暴露的往往是记录产出与流程节点脱节。复发预防的做法是把证据产出写进流程节点本身：明确每个阶段应产出哪些记录、由谁负责、在什么时点归档到受控位置，并把归档完成作为节点流转的条件之一。定期按证据清单自查，检查新增项目是否按节点留痕。具体组织方式需结合团队规模与流程成熟度选择，小团队可以简化清单，成熟度较高的团队可以把自查纳入阶段评审。
工具层面，工作项状态流转与文档库可以承载归档时点和责任人，使记录在产生时即进入受控位置，减少评估前集中补录的压力。ONES 的 ASPICE 解决方案按线上化、透明化、智能化分阶段建设，其中线上化阶段支持研发全生命周期流程活动与跨域协作的可追溯性，可作为把证据产出嵌入流程节点的一种落地路径；实施范围与版本要求需另行确认。
常见问题
评估前时间很紧，证据缺失应该先补哪一类？
优先处理影响评估关键过程的条目，例如需求追溯关系、评审记录、测试结果与缺陷处理记录，这些通常直接支撑过程域的能力判定。其次是支撑性记录，如计划、会议纪要和培训记录，最后才做一般性归档整理。
在类型上，“记录存在但未归档”通常只是整理工作量，可以较快归位；“记录从未产生”和“内容不满足要求”涉及事实判断，需要先核实再决定补录还是准备偏差说明。时间紧张时，把可快速归位的归档类条目先清掉，能为关键条目留出核实与补录的时间。
补录的记录会不会被评估方视为造假？
关键区别在于补录是否如实标注。补录说明写明原记录为何缺失、依据什么材料补录、由谁补录，等于承认记录是后补的，并给出可核查的依据，这与伪造记录性质不同。
需要守住几条边界：不伪造从未发生的活动，不倒签时间，不修改已归档记录的历史内容来制造“当时就有”的假象。当某条缺失无法在不伪造的前提下补齐时，应停止补录，转入偏差说明流程，如实说明缺口与已采取的补救措施。
核实后仍无法确认某条记录是否执行过，该怎么处理？
保留“未确认”状态，不按已执行处理，也不直接判定为未执行。这类条目在处置阶段按不可补类对待：整理能间接支撑的替代证据，例如上下游工作产品的引用关系、系统操作日志、相关活动的后续处理记录，并写入偏差说明。
偏差说明中应写清缺失条目、影响的过程域、已做的核实工作和当前状态。评估时按统一口径说明，避免同一类问题在不同条目上给出互相矛盾的解释。
偏差说明应该写到什么程度，评估方才会接受？
偏差说明的接受口径取决于具体评估机构与评估范围的要求，准备阶段应主动向评估方确认。通常需要覆盖四项内容：缺失的具体条目、影响的过程域、已采取的补救措施、当前状态与残余风险。
写法上保持事实陈述，把“确认未执行”和“未确认”分开表述，不用模糊措辞掩盖缺口。同一类缺失尽量使用统一模板和口径，由熟悉评估范围的人员确认后再定稿。
内部预审抽查多少条目才够，怎么判断证据链闭合？
预审按过程域组织，覆盖评估范围内的主要项目和阶段，而不是只看准备最充分的部分。每个过程域抽查若干条关键证据，检查三件事：能否在受控位置找到；追溯关系是否完整，例如需求到设计、设计到测试、测试到缺陷的链路是否闭合；内容是否包含评审结论、责任人、时间与版本等评估关注的信息。
通过标准可设为：关键证据可定位、可追溯、内容满足要求；补录条目均有补录说明和依据；偏差条目均有偏差说明。未达标的条目列入残余风险清单，逐条写明缺口与评估时的说明口径。
