研发审计准备的主线可以概括为五步：先书面确认审计范围与判定依据，再把审计条款拆成研发过程中的控制点，随后为每个控制点确定证据、留存位置和责任人，接着做一次抽样预审并登记缺口，最后按检查表判断是否就绪。最终交付物是一份能被审计方按条款直接调阅的证据清单，以及配套的预审记录和整改闭环记录。
要点总览（TL;DR）
- 研发审计准备按五步推进：书面确认范围与依据、把条款拆成研发过程控制点、为控制点分配证据与责任人、抽样预审并登记缺口、按检查表判定是否就绪。
- 拆解控制点时按需求、设计、开发、测试、发布、变更逐环节识别，每个控制点写清输入、动作和输出，并用对照表与审计条款双向关联。
- 证据清单要写明证据项、留存位置、责任人和截止时间；留存位置需支持按项目和时间窗定位，并保留时间、操作人和版本信息。
- 预审按控制点分层抽样，核对证据存在性、内容一致性和相互印证关系，缺口登记责任人与期限，整改后由复核人确认关闭。
- 准备完成的标志是检查表全部通过，且未参与准备的人能按条款编号独立调阅到原始证据。
先定范围与依据：审计准备从哪里开始
审计准备最常见的浪费，是在范围没定清楚时就开始大规模收材料。项目清单一变，前面收集的文档大半作废。第一步应当产出书面确认的范围与依据，让后续所有证据收集都有明确边界。
界定审计范围的三个维度
范围通常从项目、过程阶段、时间窗三个维度同时界定。项目维度要写清纳入审计的项目清单及选取理由，例如全部在研项目、某个产品线，或客户指定的交付项目。过程阶段维度要说明覆盖需求、设计、开发、测试、发布、变更中的哪些环节，以及是否包含外包或供应商协同部分。时间窗维度要写明证据的起止日期，并说明跨期项目如何切分。
三个维度确定后，建议再补一条排除说明：哪些项目、哪些阶段本次不纳入，以及排除原因。排除说明能减少审计过程中对边界的反复争议。
审计依据从哪里来
判定依据一般有四类来源：合同或客户协议中的过程与交付条款；公司内部的研发流程文件、模板和作业指导书；适用的行业标准或过程模型要求；监管或客户方指定的检查表。实际准备时，往往需要多类依据叠加使用，此时要标明每条要求的出处，避免不同文件之间口径冲突时无法判断以哪份为准。
形成书面确认
把范围与依据整理成一张确认表，内容包括：项目清单、过程范围、时间窗、适用条款编号及出处、排除项说明、确认人与确认日期。这张表由研发负责人与质量或流程负责人共同确认，必要时请客户或审计方书面认可。确认表一旦定稿，后续控制点拆解和证据收集都以它为基准，范围变更须走同样的确认流程。
把审计要求拆成研发过程控制点
审计条款通常按主题书写，研发活动按环节推进，两者之间需要一次翻译。拆解的目标是让每条要求落到具体的研发动作上，并明确这个动作应当留下什么输出。
按研发环节识别控制点
沿研发主流程逐环节过一遍，识别需要留痕的控制点：
- 需求环节：需求来源确认、需求评审、需求变更审批、需求基线建立。
- 设计环节：设计评审、接口与架构确认、设计变更记录。
- 开发环节：编码规范执行、代码评审、分支与版本管理、开发环境配置记录。
- 测试环节：测试计划与用例评审、测试执行记录、缺陷登记与关闭、测试报告。
- 发布环节：发布审批、发布记录、回滚预案、上线验证结果。
- 变更环节：变更申请、影响分析、变更评审、变更后验证。
每个控制点写清三件事：输入是什么（如需求文档、变更申请单），动作是什么（如评审、审批、验证），输出是什么（如评审纪要、审批记录、测试报告）。输出即后续证据的候选对象。
建立控制点与条款的对照
用一张对照表把控制点与审计条款双向关联：每条条款对应哪些控制点，每个控制点支撑哪些条款。对照时注意两种情况：一条条款可能需要多个控制点共同支撑，例如“变更受控”可能同时涉及变更审批、影响分析和变更后验证；一个控制点也可能同时支撑多条条款。对照表要保留条款编号，便于预审和正式审计时按条款反查。
| 审计条款 | 对应控制点 | 输入 | 动作 | 输出 |
|---|---|---|---|---|
| 需求变更须经评审 | 需求变更审批 | 变更申请单 | 评审会、审批签署 | 评审纪要、审批记录 |
| 代码须经评审后合入 | 代码评审 | 合并请求 | 评审人审查、意见处理 | 评审意见与合入记录 |
| 发布须经授权 | 发布审批 | 发布申请、测试报告 | 审批签署、发布执行 | 审批记录、发布记录 |
对照表完成后，请一位不参与日常执行的人按条款逐条读一遍，检查是否存在“条款有、控制点无”的空档。这类空档往往就是预审阶段最容易暴露问题的地方。
确定证据类型、留存位置与责任人
控制点确定后，准备工作转入执行层：每个控制点需要什么证据、证据存在哪里、由谁负责在什么时间前交出来。这一节产出的是可以直接分发的证据清单。
常见证据类型
研发审计中反复出现的证据包括：评审记录（需求评审、设计评审、代码评审、测试用例评审）、审批记录（变更审批、发布审批、例外审批）、测试报告与测试执行记录、变更单及影响分析、缺陷记录与关闭说明、发布记录与上线验证结果、培训与资质记录、工具配置与环境记录。每类证据要注明是原始记录还是汇总报告，审计通常更认可带时间戳和操作人的原始记录。
留存位置与可追溯性
证据的留存位置要满足三个条件：能定位到具体项目和时间段；能看出谁在什么时候做了什么；版本可区分，避免用最新版覆盖历史版本。常见位置包括研发管理平台中的工作项与评审记录、文档管理系统中的受控文档、测试管理系统中的执行记录、代码仓库中的合并请求与提交历史。清单中应写明每项证据的具体位置路径或查询方式，而不是只写“在系统里”。
责任人分配与交接
责任人按“谁执行、谁留存”的原则分配：评审记录由评审组织者负责，测试报告由测试负责人负责，发布记录由发布执行人负责。跨角色交接时，用清单上的状态字段确认，例如“已提交”“已核对”“已归档”，交接双方在清单上留名和日期。责任人变更时同步更新清单，避免出现无人认领的证据项。
| 证据项 | 对应控制点 | 留存位置 | 责任人 | 截止时间 |
|---|---|---|---|---|
| 需求评审纪要 | 需求评审 | 文档库受控目录 | 需求负责人 | 预审前一周 |
| 代码评审记录 | 代码评审 | 代码仓库合并请求 | 开发组长 | 预审前一周 |
| 测试报告 | 测试执行 | 测试管理系统 | 测试负责人 | 预审前三天 |
| 发布审批与发布记录 | 发布审批 | 研发管理平台工作项 | 发布执行人 | 预审前三天 |
当评审记录、审批状态和发布记录分散在多个工具中时，证据的调阅成本会明显上升。ONES 可以把需求、任务、缺陷等工作项与评审、审批状态放在同一条记录链上，文档状态变更留有时间与操作人，预审时按项目和时间窗筛选即可定位，减少逐个人工询问的环节。
做一次内部预审：抽样、核对与缺口登记
证据收齐不等于准备完成，需要一次内部预审来验证证据是否真的支撑条款。预审的价值在于把问题暴露在正式审计之前，并转成有责任人和期限的整改任务。
抽样方法与样本量
抽样按控制点分层进行：对高频、高风险控制点（如代码评审、变更审批）抽取较多样本，对低频控制点可全量核对。样本量没有统一标准，可按项目数量、时间窗长度和条款重要性确定，例如每个控制点至少覆盖每个纳入项目各两份样本，并确保时间窗的首尾各有样本。抽样时记录抽样规则和样本编号，便于复核。
逐项核对一致性
核对三件事：证据是否存在；证据内容是否与条款要求一致，例如评审记录是否包含评审人、评审结论和处理意见；证据之间是否互相印证，例如变更单上的变更内容能否在测试记录和发布记录中找到对应。发现“有记录但内容不完整”的情况，按缺口处理，不按通过处理。
缺口登记与整改
每个缺口登记：缺口描述、对应条款、责任人和整改期限、整改方式（补记录、补审批、补充说明）、复核人。整改完成后由复核人确认关闭，清单上保留关闭日期。对无法补齐的历史记录，写明原因和替代说明，由研发负责人确认，避免在正式审计时临时解释。
角色分工与交付物一览
审计准备涉及多个角色，职责边界不清时容易出现重复收集或关键证据无人负责。下表按角色列出主要职责、交付物和提交时点，可作为责任矩阵的起点，再按团队实际情况调整。
| 角色 | 主要职责 | 交付物 | 提交时点 |
|---|---|---|---|
| 研发负责人 | 确认审计范围与依据，裁定缺口整改方案 | 范围与依据确认表、整改裁定记录 | 准备启动时、预审后 |
| 项目经理 | 组织本项目证据收集，跟踪清单状态 | 项目证据清单、缺口整改进度 | 预审前、整改期内 |
| 质量或流程负责人 | 拆解控制点、编制对照表、执行预审 | 控制点—条款对照表、预审记录 | 准备中期、预审时 |
| 各环节执行人 | 按清单提交本环节证据，处理本人缺口 | 评审记录、测试记录、变更单等原始证据 | 按清单截止时间 |
跨角色交接用清单状态和签字确认：证据提交后在清单上标记状态，接收方核对后标记“已核对”，双方留名和日期。预审记录和整改清单由质量或流程负责人汇总，向研发负责人汇报，形成一条从发现到关闭的记录链。
一个完整示例：从范围确认到证据包交付
以下为演示情景，用于说明步骤如何串联，不代表任何真实项目。
某团队接到客户通知，将在两个月后对一条产品线的研发过程进行审计。团队先确认范围：纳入该产品线三个在研项目，覆盖需求到发布全流程，时间窗为过去十二个月，依据为客户合同附件中的过程条款和公司研发流程文件，形成确认表并由研发负责人与客户对接人签字。
随后质量负责人按条款拆出二十余个控制点，建立对照表，发现“变更后验证”一条在现有流程文件中没有明确输出，补充了变更验证记录模板。证据清单按控制点分配到三个项目的项目经理和各环节执行人，明确留存位置和截止时间。
预审阶段按控制点抽样，每个项目每个控制点抽两份样本。核对中发现两类缺口：部分早期代码评审只在聊天工具中留有讨论，未形成正式评审记录；两次发布缺少审批签署。缺口登记后，评审记录缺口通过补充评审说明并由评审人确认的方式处理，发布审批缺口由发布执行人补充审批并说明原因，均在两周内关闭。
最终证据包按条款编号组织：每条条款下放置对应证据的索引、存放位置和责任人，附预审记录与缺口关闭记录。审计方按条款调阅时，可直接从索引定位到原始记录。
完成检查：审计准备就绪的判定标准
准备是否到位，可以用下面这份检查表逐项核对。全部条目为“是”并有记录支撑，才建议进入正式审计。
- 范围与依据已书面确认：项目清单、过程范围、时间窗、适用条款及出处齐全，确认人和日期可查。
- 控制点拆解完整：每条审计条款至少对应一个控制点，对照表经过独立复核，无“条款有、控制点无”的空档。
- 证据与责任人落实：每个控制点在证据清单中有证据项、留存位置、责任人和截止时间，无未分配项。
- 证据可追溯：证据带时间、操作人和版本信息，能按项目和时间窗检索。
- 预审已执行：抽样规则和样本有记录，核对结论有依据。
- 缺口闭环：每个缺口有责任人、期限、整改结果和复核关闭记录，无法补齐的有书面说明和负责人确认。
- 证据包可按条款调阅：按条款编号能在一到两步内定位到原始证据，索引与实际存放位置一致。
检查中发现未通过项，回到对应步骤补齐，而不是在正式审计前临时补材料。准备工作的完成标志，是这份检查表全部通过，且证据包能被一位未参与准备的人按条款独立调阅。
常见问题
审计范围在准备过程中发生变化，已经收集的证据怎么处理？
范围变更应走与初次确认相同的书面流程：更新确认表中的项目清单、过程范围或时间窗，注明变更原因和确认人。已收集的证据按新范围重新判定归属，落在新范围外的证据从清单中移出但保留存档，落在新范围内的缺口重新分配责任人和截止时间。变更后建议重跑一次对照表复核，确认条款与控制点的对应关系没有因范围调整而出现空档。
历史项目缺少评审记录或审批签署，正式审计前还能补吗？
能否补齐取决于记录的性质和审计方的要求。可以补的是说明性材料，例如由当时的参与人出具补充说明，写明评审时间、参与人、结论和未留正式记录的原因，并由研发负责人确认。不宜做的是倒签日期或事后伪造签署，这类做法一旦被发现，影响远大于记录缺失本身。对确实无法补齐的项，在缺口清单中写明原因和替代说明，提前与审计方沟通处理方式，把解释工作放在正式审计之前。
多个项目共用一套流程，证据清单需要每个项目各做一份吗？
建议保留一份统一模板，按项目分别实例化。模板层面固定控制点、证据类型和留存位置要求，保证不同项目的口径一致；项目层面填写具体的证据项、责任人、截止时间和实际存放路径。这样既避免每个项目各自设计清单造成遗漏，也便于预审时横向比较各项目的完成情况。共用流程文件、模板等全局性证据可以只准备一份，在清单中注明适用范围。
预审抽样发现的问题很少，是否可以直接进入正式审计？
抽样结果少不代表准备充分，需要先确认抽样是否覆盖了时间窗首尾、高风险控制点和不同项目。如果样本集中在近期或单一项目，问题可能被掩盖。建议在预审记录中写明抽样规则和覆盖情况，由未参与日常执行的人复核一遍条款与控制点的对应关系。确认覆盖充分且缺口全部闭环后，再按检查表逐项判定是否就绪。
证据分散在多个工具中，如何降低正式审计时的调阅成本？
核心是建立一份按条款编号组织的索引，每条条款下列出对应证据的名称、存放位置、责任人和查询方式，索引与实际存放位置保持一致。对于评审、审批、发布等记录，尽量让状态和操作人留在同一条记录链上，减少跨工具拼接。ONES 可以将需求、任务、缺陷等工作项与评审、审批状态关联，文档状态变更留有时间与操作人，预审和正式审计时按项目和时间窗筛选即可定位。
