研发过程审计要回答的是“团队是否按既定流程做了、有没有留下可核查的记录”。可执行的做法是按“定范围—立基准—取证据—做核验—出结论—跟踪整改”六步推进，每一步都产出明确文档，最后用闭环清单验收。审计结论只说明过程符合性，不替代认证结论或法律判断。
要点总览（TL;DR）
- 研发过程审计按“定范围—立基准—取证据—做核验—出结论—跟踪整改”六步推进，每步都有明确交付物和完成标志。
- 判定基准要写明文件名称、版本和适用条款，检查项按“要求—动作—证据—通过标准”拆解，并区分强制项与建议项。
- 证据优先从工作项、评审、变更、测试记录中抽取并编号，每条判定都能按编号回溯到原始记录。
- 审计负责人、审计员、被审计方、流程Owner四类角色职责分开，审计员不审计本人直接负责的工作。
- 闭环验收看五项：范围与基准覆盖计划对象、证据可追溯、不符合项有责任人和时限、整改已验证关闭、记录已归档。
审计前先定范围、周期与判定基准
审计启动阶段最容易失控的地方是边界不清：审计员想查全部项目，被审计方不知道要准备什么，最后变成翻文件。先写一份审计范围说明书，把“查谁、查什么、查多久、按什么判”四件事定下来，后续取证才有依据。
审计对象与边界要写到可操作的程度。对象可以是某个项目、某个阶段的交付物，或某类流程域（如需求变更、代码评审、测试准入）。边界要说明包含哪些项目或团队、覆盖哪些阶段、排除哪些内容及排除理由。例如“本次审计覆盖A产品线2024年Q2立项的3个项目，范围从需求评审到版本发布，不包含供应商管理流程”。
审计周期与触发方式通常有三类：定期审计按季度或半年滚动覆盖；里程碑审计在重要版本发布、阶段评审前进行；事件触发审计在出现重大质量事故、客户投诉或流程变更后启动。三类方式可以并存，但每次审计要写明本次属于哪一类，避免周期和触发条件混用导致重复审计或漏审。
判定基准来源需要逐条列明出处。常见来源包括组织内部的研发流程文件、适用的行业标准条款、客户合同中的过程要求。基准清单要记录文件名称、版本号、生效日期和适用条款，避免用过期版本做判定。行业标准的具体条款编号由组织根据自身适用范围确定，本文不提供认证层面的条款解释。
抽样规则要在启动时确定。按项目抽样时，可覆盖全部在研项目或按风险选取；按工作项抽样时，可对每个流程域抽取固定数量或按比例抽取。样本量确定方法建议考虑三个因素：流程域的风险等级、历史不符合项分布、本次审计可用的人力。抽样规则写入范围说明书后，执行中如需调整，要记录调整原因和审批人。
本阶段交付《审计范围说明书》和《判定基准清单》。完成标志是：审计对象、边界、周期、基准来源、抽样规则五项均有明确文字，且经审计负责人确认。
把流程要求拆成可核查的审计条款
流程文件通常写的是原则性要求，直接拿来审计会出现“看起来都符合、又说不出哪里不符合”的情况。需要把每条要求拆成“要求—动作—证据—通过标准”四段，形成条款级检查表。
拆解方法可以按这个顺序走：先从流程文件中摘出要求原文；再识别该要求对应的研发动作，即谁在什么阶段做什么；然后确定该动作应留下的证据类型，如工作项状态记录、评审意见、变更单、测试报告；最后写出通过标准，即证据满足什么条件判定为符合。以“需求变更需经评审”为例：要求是变更受控，动作是提交变更申请并组织评审，证据是变更单及评审记录，通过标准是评审参与人符合规定角色、评审结论明确、变更单状态与评审结论一致。
检查项字段建议包含：条款编号、条款名称、适用阶段、要求描述、对应动作、证据来源、判定规则、强制或建议属性、对应流程文件条款号。字段设计的目标是让不同审计员对同一条款能得出一致判定，减少个人经验差异带来的偏差。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 条款编号 | 唯一且稳定，便于跨次审计对比 | REQ-03 |
| 适用阶段 | 写明流程阶段或里程碑 | 需求评审后至开发启动前 |
| 证据来源 | 指明记录类型和存放位置 | 变更单、评审记录 |
| 判定规则 | 可观察、可复核的条件 | 评审结论为通过且参与角色齐全 |
| 属性 | 强制项或建议项 | 强制项 |
强制项与建议项要分开标注。强制项不符合时进入不符合项清单并跟踪整改；建议项不符合时作为改进建议记录，不必然触发整改流程。区分标准由组织在流程文件中预先规定，审计员不在现场临时决定。
条款与流程文件的对应关系需要维护。流程文件修订后，检查表要同步更新对应条款号和判定规则，并记录变更历史。否则会出现审计依据已更新、检查表仍是旧版的情况，导致判定争议。
本阶段交付《审计检查表（条款级）》。完成标志是：每条强制项都有明确的证据来源和判定规则，且检查表版本与判定基准清单中的文件版本一致。
按步骤执行审计：取证、核验与记录偏差
执行阶段的核心是让每条判定都能回溯到具体证据。建议按“取证—核验—记录偏差—沟通澄清”的顺序推进，每一步都有输入、动作和输出。
取证环节从过程记录中提取证据。常用来源包括工作项记录（状态流转、负责人、完成时间）、评审记录（参与人、意见、结论）、变更记录（变更内容、审批链）、测试记录（用例执行、缺陷状态）。取证时给每条证据编号，记录来源位置和提取时间。证据可以是截图、导出记录或系统查询结果，关键是能让他人按编号复核。
研发过程的活动和记录往往分散在多个系统中，取证效率取决于记录是否集中可查。ONES 可以承载工作项、评审和变更等过程记录，审计时按项目和时间范围查询相关记录，能减少跨系统收集证据的往返。具体查询与导出能力以实际版本为准，选型时可向厂商核实。
核验环节逐条比对证据与通过标准。对每条检查项，写明证据编号、比对结果（符合、不符合、部分符合、不适用）和判定说明。判定为“不适用”时要写明理由，例如该阶段在本次审计范围内未发生。核验由审计员完成，复杂条款可安排两人独立判定后比对结果。
偏差记录要写清四件事：不符合项描述（哪条要求、哪个对象、什么现象）、证据编号、影响判断（对交付质量或后续阶段的影响程度）、初步分类（强制项或建议项）。描述避免笼统，例如“变更单CHG-012缺少测试负责人评审意见，评审记录中仅有开发与产品角色”，比“变更评审不规范”更可核查。
审计过程中的沟通与澄清机制要提前约定。被审计方对证据或判定有异议时，可在规定时限内提交补充材料或说明，审计员核实后决定是否调整判定，调整要记录理由。沟通记录随工作底稿归档，避免审计结束后才出现争议。
本阶段交付《审计工作底稿》和《不符合项清单》。完成标志是：每条检查项都有判定结果和证据编号，每个不符合项都有描述、证据和影响判断。
角色分工与各环节交付物
审计职责不清的典型表现是：审计员既取证又替被审计方解释流程，流程Owner在报告发布后才看到结论。需要在启动时明确四类角色的职责边界和交付物。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 审计负责人 | 确定范围与基准、批准审计计划、审定报告、裁决争议 | 范围说明书、审计计划、审计报告 |
| 审计员 | 拆解条款、取证、核验、记录偏差、编写底稿 | 检查表、工作底稿、不符合项清单 |
| 被审计方 | 提供记录、配合澄清、制定并执行整改措施 | 证据材料、澄清说明、整改计划与完成记录 |
| 流程Owner | 确认判定基准、评审不符合项、推动流程改进 | 基准确认意见、整改验收意见、流程修订建议 |
各角色在关键环节的交付物要对应起来：取证阶段由被审计方提供材料、审计员编号归档；核验阶段由审计员出具判定、审计负责人抽查复核；报告阶段由审计负责人审定、流程Owner会签；整改阶段由被审计方提交完成记录、审计员复核验证、流程Owner确认关闭。
审计独立性要求审计员不审计本人直接负责的工作。涉及本人参与的项目或流程域时，应安排回避或由其他审计员执行该部分核验。回避安排写入审计计划，避免执行中临时调整。
审计结果的审批与发布路径按组织规定执行，通常由审计负责人审定后经流程Owner会签，再向被审计方及相关管理层发布。发布范围、保密要求和异议受理时限在审计计划中写明。
本阶段交付《角色职责表》和《交付物清单》。完成标志是：每个环节都有明确责任人和产出物，且不存在同一人既执行又验收的情况。
审计报告与整改跟踪示例
审计报告要让读者不看底稿也能理解结论和依据。建议结构为：审计范围与方法、判定基准、发现汇总、不符合项明细、总体结论、改进建议。总体结论只描述过程符合性，例如“本次审计覆盖3个项目、42条强制项，其中38条符合、4条不符合”，不写认证或法律层面的判断。
以下为演示情景，用于说明不符合项从记录到关闭的写法，不代表真实案例。某项目变更单CHG-012涉及接口协议调整，检查项REQ-03要求变更经测试负责人评审。审计员取证发现评审记录仅有开发与产品角色参与，判定为不符合。记录如下：
| 字段 | 内容 |
|---|---|
| 不符合项编号 | NC-07 |
| 条款与对象 | REQ-03，项目A，变更单CHG-012 |
| 证据编号 | EV-031（变更单）、EV-032（评审记录） |
| 影响判断 | 接口协议变更未经测试侧评审，测试用例覆盖可能不完整 |
| 根因 | 变更流程未明确测试负责人为必选评审角色 |
| 整改措施 | 补充测试评审并更新变更模板中的评审角色清单 |
| 责任人 | 项目A变更管理员 |
| 关闭时限 | 审计报告发布后10个工作日内 |
整改验证与关闭标准要事先约定：被审计方提交整改完成记录和补充证据，审计员核对证据是否满足原判定规则，满足则关闭，不满足则退回并重新计时。关闭记录中保留原证据编号和新证据编号，形成可追溯链条。
复发预防与趋势分析在多次审计后才有意义。可按条款编号统计不符合项分布，识别高频条款，反馈给流程Owner评估是否需要修订流程文件或加强培训。单次审计的结论用于本次整改，趋势分析用于流程改进，两者分开呈现，避免把个案上升为普遍结论。
本阶段交付《审计报告》和《整改跟踪表》。完成标志是：每个不符合项都有责任人、时限和验证记录，报告经审批发布。
完成检查：审计闭环的验收标准
判断一次审计是否做完、做到位，可以逐项核对以下清单。全部满足才视为闭环，存在未满足项时写明原因和后续安排。
- 范围与基准：审计范围说明书覆盖计划内的项目、阶段和流程域；判定基准清单中的文件版本与检查表一致，无过期依据。
- 条款完整：强制项均有证据来源和判定规则；建议项单独标注；条款与流程文件条款号可对应。
- 证据可追溯：每条判定都有证据编号，证据可按编号定位到原始记录；证据提取时间和来源已记录。
- 偏差记录完整：每个不符合项都有描述、证据编号、影响判断、根因、整改措施、责任人和关闭时限。
- 整改已验证：不符合项均有复核记录，关闭项保留原证据和新证据；未关闭项有明确的后续跟踪安排。
- 角色履职：取证、核验、审批、整改各环节的责任人已实际执行，回避安排已落实。
- 记录归档：范围说明书、检查表、工作底稿、报告和整改跟踪表统一归档，可供下次审计复用和对比。
清单核对完成后，由审计负责人确认闭环状态并在报告中标明。未闭环的事项转入下一周期跟踪，不因本次审计结束而丢失。
常见问题
审计周期定多长合适，定期审计和事件触发审计怎么配合？
周期取决于流程域的风险等级和可用人力，常见做法是高风险流程域按季度覆盖、其他流程域按半年滚动。定期审计负责保证覆盖面，事件触发审计在重大质量事故、客户投诉或流程变更后启动，只针对相关流程域和项目，不重复全量审计。每次审计在范围说明书中写明本次属于哪一类，并记录与上次审计的时间间隔和覆盖对象，避免同一项目在短期内被重复审计，也避免某些项目长期未覆盖。
被审计方对判定结果有异议，处理流程怎么定？
在审计计划中约定异议受理时限，例如报告初稿发出后5个工作日内。被审计方提交补充材料或书面说明，审计员核实后决定维持或调整判定，调整要记录理由和新增证据编号。争议无法在审计员层面解决时，由审计负责人裁决，涉及判定基准理解分歧的，请流程Owner出具基准确认意见。异议处理记录随工作底稿归档，报告发布后不再受理同一事项的重复申诉。
审计员人手有限时，抽样和核验怎么安排才不影响结论可信度？
先按风险排序，把人力集中在高风险流程域和历史上不符合项集中的条款上，低风险条款可降低抽样比例但要在范围说明书中写明理由。核验环节对判定规则复杂或争议可能性高的条款安排两人独立判定后比对，其余条款由单人判定、审计负责人抽查复核。抽查比例和复核范围写入审计计划，报告的方法部分如实说明抽样范围和复核方式，让读者知道结论的覆盖边界。
流程文件在审计期间修订了，检查表和判定怎么处理？
以审计范围说明书中锁定的基准版本为准，审计期间新发布的流程文件不改变本次判定标准。若修订内容影响正在核查的条款，由流程Owner确认是否将相关条款纳入下次审计，并在本次报告中注明版本差异。检查表要记录变更历史，流程文件修订后同步更新条款号和判定规则，保证下次审计使用的检查表与当时有效的基准一致。
多次审计后怎么用历史数据改进流程，而不是只做单次整改？
按条款编号汇总历次不符合项，统计高频条款和重复发生的项目，反馈给流程Owner评估是流程文件表述不清、培训不到位还是执行环节缺少必要角色。趋势分析结论与单次审计结论分开呈现，单次结论用于本次整改关闭，趋势结论用于流程修订和培训计划。分析时注意样本量，审计次数少或覆盖项目少时，结论只作为观察线索，不直接作为流程变更依据。
