研发审计准备的核心，是把审计可能问到的问题提前落到研发过程的活动、记录和责任人上。具体做法是：按审计范围拆出过程域与证据项，逐项核对现有记录是否齐全、可追溯、版本一致，补齐缺口并明确每类证据的负责人，最后用一次内部预审验证证据链能否支撑审计问询。本文按证据清单、填写口径、角色分工、缺口整改与预审、链路示例和就绪检查的顺序展开，适用于研发过程符合性审计的准备，不涉及认证结论与法律合规判断。
要点总览（TL;DR）
- 研发审计准备从审计范围与依据出发，按需求、设计、开发、测试、发布、变更、缺陷等过程域拆出证据项，形成可直接核对的证据清单。
- 证据项要写到可核查粒度，注明责任角色、存放位置、版本时效与状态，并用需求编号等关联标识串起需求到发布的链路。
- 角色分工建议覆盖牵头人、过程域负责人、质量或合规角色和研发团队，用 RACI 矩阵明确各自交付物与交接节点。
- 核对后的缺口按记录缺失、不完整、版本不一致、无法追溯分类整改，再通过抽样核对与模拟问询完成内部预审。
- 准备就绪的判断看清单覆盖率、关键过程域有无阻断性缺口、责任人与存放位置是否明确、预审问题是否闭环。
研发审计准备先做什么：从审计范围到证据清单
准备工作的起点是确定审计范围与依据。范围决定要查哪些项目、哪些阶段、哪个时间区间；依据决定每项证据要满足什么要求。常见依据包括体系标准、客户合同中的过程要求、公司内部研发规范。三者可能同时存在，准备时应先列出适用依据清单，注明每条依据对应的条款或要求出处，避免后续核对时口径不一。
范围明确后，按研发过程域拆分证据项。典型拆分方式为：需求、设计、开发、测试、发布、变更、缺陷。每个过程域下再列出该域应有的客观证据，例如需求域对应需求文档、需求评审记录、需求变更审批；设计域对应设计说明、设计评审单、基线记录；开发域对应代码提交记录、代码评审记录；测试域对应测试计划、测试用例、测试报告、缺陷跟踪记录；发布域对应发布审批、发布记录、版本基线；变更域对应变更申请、影响分析、变更审批与验证记录；缺陷域对应缺陷登记、分级、修复与回归验证记录。
把上述内容整理成证据清单，建议至少包含以下字段：
| 字段 | 填写内容 | 作用 |
|---|---|---|
| 证据项 | 具体记录名称，如“需求评审记录” | 明确要核对的对象 |
| 对应过程活动 | 该记录产生于哪个活动，如“需求评审会议” | 建立证据与活动的对应关系 |
| 责任角色 | 负责提供和确认该证据的岗位 | 落实准备责任 |
| 存放位置 | 系统、目录或档案编号 | 保证审计时能快速调取 |
| 当前状态 | 已有、缺失、部分满足、待确认 | 支撑缺口统计与整改排序 |
清单形成后，准备工作的第一项产出即告完成：一份按过程域组织、字段完整、可直接用于逐项核对的证据清单。后续填写与核对都以此为基础。
证据清单怎么填：字段口径与可追溯要求
证据项的描述要写到可核查粒度，即说清“谁在什么时点产出什么记录”。例如“需求评审记录”应细化为“需求负责人在需求基线确定前组织评审并形成的评审结论记录”，包含评审参与人、评审意见和处理结果。只写活动名称的条目无法直接核对，容易在预审时反复澄清。
可追溯要求体现在记录之间的关联关系上。一条需求应能沿需求编号关联到对应的设计说明、测试用例和发布版本，形成需求到设计、设计到测试、测试到发布的链路。填写清单时，应为每个证据项注明其关联标识，例如需求编号、版本号、缺陷编号，便于抽查时顺链核对。
版本与时效同样需要在清单中体现。每条记录应标注是否为当前有效版本，以及是否覆盖审计区间。已被替代的历史版本要注明替代关系，区间外的记录单独标记，避免把过期记录当作有效证据提交。
状态标记建议统一为四类：已有，指记录齐全且符合口径；缺失，指应有而完全没有；部分满足，指记录存在但内容不全或关联断裂；待确认，指记录存在但有效性尚需责任人核实。状态标记应随核对进展更新，作为缺口统计和整改排序的依据。
角色与交付物：谁负责准备、谁负责确认
审计准备不宜集中在单一岗位。建议设置四类角色，各自承担明确的交付物：
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 审计准备牵头人 | 统筹证据清单、准备节奏与对外沟通 | 证据清单总表、准备计划、对外沟通记录 | 清单初稿完成后分发；预审前汇总 |
| 过程域负责人 | 提供本领域证据并确认完整性 | 本域证据及状态确认 | 收到清单后按约定时限回填 |
| 质量或合规角色 | 核对证据与依据的对应关系 | 依据对照说明、口径问题清单 | 过程域回填后集中核对 |
| 研发团队 | 补齐缺失记录、确认数据真实 | 补录记录、真实性确认 | 缺口清单下发后整改 |
责任矩阵可采用 RACI 形式标注：每项证据由谁负责执行（R）、谁负责审批确认（A）、谁需要被咨询（C）、谁需要被知会（I）。例如需求评审记录，需求负责人为 R，过程域负责人为 A，质量角色为 C，牵头人为 I。矩阵确定后，各角色的交接节点应写入准备计划，包括清单分发、回填截止、核对完成、整改完成和预审五个节点，每个节点明确输出物和确认人。
当研发活动的工作项、评审和审批在统一平台上流转时，证据的收集与状态确认可以依托平台记录完成。ONES 支持将需求、任务、缺陷等工作项与评审、审批流程关联，过程记录随工作项状态变化留存，便于按项目和时间区间检索；准备阶段可由过程域负责人直接在系统中核对记录并回填清单状态，减少线下收集造成的版本不一致。具体可用范围以实际部署和配置为准。
缺口整改与内部预审：把问题在审计前解决
核对完成后，按缺口类型分类处置。记录缺失的，由责任团队补录或说明原因；记录不完整的，补充缺失字段或附件；版本不一致的，确认有效版本并标注替代关系；无法追溯的，补充关联标识或说明链路断点。每类整改都要写明完成标志，例如“补录评审记录并经过程域负责人确认”“需求与测试用例关联标识补齐并经抽查验证”。整改情况记入缺口整改记录表，包含缺口描述、类型、责任人、整改动作、完成标志和完成日期。
整改基本完成后组织内部预审。预审采用抽样核对与模拟问询两种方式：抽样核对从每个过程域抽取若干条记录，沿需求到发布链路验证关联是否完整；模拟问询由质量或合规角色扮演审计方，就证据的有效性、版本和审批过程提问，检验责任人能否当场说明并调取记录。预审发现的问题同样进入整改记录，形成闭环，未闭环事项需在正式审计前给出处理结论或风险说明。
示例：一次需求到发布链路的证据核对
以下为演示情景，用于说明核对方法，不代表任何具体组织的实际审计结果。
选取需求编号 REQ-102 作为样本，逐环节核对：
| 环节 | 应有证据 | 实际状态 | 处理方式 |
|---|---|---|---|
| 需求 | 需求说明、评审记录、基线记录 | 已有 | 核对评审参与人与结论完整 |
| 设计 | 设计说明、设计评审单 | 部分满足：评审单缺少审批签字 | 由设计负责人补充审批并确认 |
| 开发 | 代码提交记录、代码评审记录 | 已有 | 核对提交记录与需求编号关联 |
| 测试 | 测试用例、测试报告、缺陷记录 | 缺失：测试用例未关联需求编号 | 补充关联标识后重新抽查 |
| 发布 | 发布审批、发布记录、版本基线 | 已有 | 确认发布版本与测试通过版本一致 |
该示例中，缺口集中在审批完整性和关联标识两类，整改动作明确、可验证。需要说明的是，不同研发模式（如迭代交付、外包协作、多产品线并行）的过程域划分和证据项会有差异，采用敏捷迭代的团队可将评审记录与迭代回顾记录纳入证据范围，外包场景还需补充供方过程记录，实际准备时应按自身过程裁剪证据清单。
完成检查：审计准备就绪的判断标准
准备是否就绪，可按以下条目逐项判断：
- 证据清单覆盖率：审计范围内各过程域的证据项均已列入清单，无遗漏过程域。
- 状态分布：清单中“已有”占比达到预期，“缺失”和“部分满足”项均有对应整改记录。
- 关键过程域无阻断性缺口：需求、测试、发布等关键域不存在无法在审计前补齐的缺失或追溯断点。
- 责任人与存放位置明确：每项证据均有责任角色和可调取的存放位置，抽查时可当场定位。
- 预审问题闭环：预审发现的问题均已整改或给出处理结论，未闭环事项附风险说明。
- 未解决事项有交代：对确实无法在审计前解决的问题，形成书面说明，注明原因、影响范围和后续计划。
上述条目全部满足或未满足项均有明确交代时，即可进入正式审计。就绪检查表建议由牵头人汇总、质量或合规角色复核，作为准备阶段结束的确认依据。
常见问题
审计区间内部分记录确实无法补齐，准备阶段应该怎么处理？
先判断该缺口是否落在关键过程域上。若属于关键过程域的阻断性缺口，应优先协调资源补齐，或调整审计范围与依据的适用说明。若确实无法在审计前补齐，形成书面说明，写清缺口内容、原因、影响范围和后续计划，并在预审结论中列为未闭环事项。正式审计时主动说明，比被问询时临时解释更可控。
研发团队日常已经在平台上流转工作项，还需要单独整理证据吗？
平台记录可以减少线下收集的工作量，证据清单仍然需要。清单的作用是明确审计范围内每个过程域应有哪项记录、由谁负责、放在哪里、当前状态如何，平台记录则作为这些证据项的来源。准备时应把清单中的存放位置指向具体系统或目录，并由过程域负责人逐项确认记录的有效版本与审计区间覆盖情况。
采用敏捷迭代或外包协作模式，证据清单需要怎么调整？
过程域划分可以保留，证据项按实际过程裁剪。敏捷迭代团队可将迭代计划、评审记录与回顾记录纳入证据范围，用迭代编号替代部分阶段基线作为关联标识。外包协作场景需补充供方过程记录、交付确认与验收记录，并明确供方与内部团队各自的责任角色。调整后的清单仍需保持字段完整，便于逐项核对。
内部预审需要覆盖全部证据项吗？
预审以抽样为主，不必逐项全查。抽样时每个过程域至少抽取若干条记录，沿需求到发布链路验证关联是否完整，重点覆盖关键过程域和状态为“部分满足”“待确认”的条目。模拟问询可针对抽样记录展开，检验责任人能否当场说明并调取。预审发现的问题进入整改记录闭环，未闭环事项在就绪检查时单独交代。
准备阶段整理的证据清单和整改记录，正式审计时如何使用？
证据清单可作为审计期间的调取索引，按过程域和存放位置快速定位记录；整改记录用于说明缺口已如何处理。两者配合预审结论，能帮助责任人在问询时给出前后一致的说明。审计结束后，这些材料也可作为下一轮准备的基线，按新的审计范围和依据更新字段与状态。
