研发过程审计要解决的问题，是把写在流程文件里的要求，对应到项目里真实发生过的活动和留存记录上，再据此判断过程是否符合。它通常由研发管理者、质量或流程负责人发起，覆盖立项、需求、设计、开发、测试、发布等环节。本文给出从定范围到整改复验的六步做法、证据清单模板、角色分工与完成检查清单，审计结论限定在过程符合性与证据充分性范围内，不替代认证审核或法律判断。
要点总览（TL;DR）
- 研发过程审计先确定三件事：审计范围（项目类型、阶段、团队、时间窗）、依据文件版本与生效日期、符合/部分符合/不符合/不适用四类判定口径及证据门槛。
- 证据清单把每条流程要求拆成可观察动作，字段包括要求编号、要求描述、对应活动、责任角色、证据类型、留存位置和抽样方式，要求描述避免“加强评审”这类无法核验的表述。
- 执行按六步推进：定范围与依据、建证据清单、确认角色与节点、抽样核查、记录结论、整改与复验；抽样核查组合记录比对、人员访谈与系统记录核对。
- 判定权集中在审计负责人，过程负责人可对事实提出异议但结论调整需记录理由；不符合项按事实、依据条款、影响、整改要求、期限五要素描述。
- 审计交付前逐项检查证据覆盖、结论一致、不符合项完整、复验安排、结论边界与归档完整性；多项目场景可用工作项与文档承载证据链和整改状态。
研发过程审计先定什么：范围、依据与判定口径
审计启动前如果没有把范围、依据和判定口径写清楚，执行阶段很容易变成”看到什么查什么”，结论也难以复现。这三项输入应当在审计计划中一次确定，并由审计负责人与过程负责人共同确认。
审计范围要写明四件事：覆盖哪些项目类型（如新产品研发、平台迭代、客户定制交付）、覆盖哪些阶段（如从立项到发布，或只审需求与测试两个环节）、涉及哪些团队与角色、时间窗从何时到何时。范围写得越具体，抽样越有依据。例如”审计2024年第二季度进入测试阶段的三个业务线项目，覆盖需求变更与测试准入两个环节”，比”审计研发流程执行情况”更可执行。
审计依据要列出被审计方应当遵守的文件清单，并注明版本号与生效日期。常见依据包括内部研发流程规范、项目立项与变更管理制度、评审管理要求、测试与发布规范。同一份文件存在多个版本时，以审计时间窗内生效的版本为准；如果期间发生过流程改版，需要说明按哪个版本判定，避免用新要求追溯旧项目。
判定口径建议统一为四类结论，并为每类设定证据门槛，使不同审计人员对同一事实得出相同结论。
| 结论类型 | 定义 | 证据门槛 |
|---|---|---|
| 符合 | 要求涉及的活动已执行，记录完整且可追溯 | 抽样项均有对应记录，记录内容与要求一致，能定位到具体项目、时间与责任人 |
| 部分符合 | 活动已执行，但记录缺失要素或执行方式与要求存在偏差 | 存在活动痕迹，但缺少审批、缺少关键字段或时间顺序不符 |
| 不符合 | 要求涉及的活动未执行，或无法提供任何有效证据 | 抽样项无记录，或记录与事实明显矛盾且无法补充说明 |
| 不适用 | 该要求不适用于被抽样的项目类型或阶段 | 需写明不适用理由，例如项目未涉及该环节 |
这三项确定后，形成一页《审计范围与依据说明》，附判定口径表，作为后续证据清单和结论记录的基准文件。
把过程要求拆成证据清单：字段与填写方法
证据清单是审计能否落到实处的关键。它的作用是把每条流程要求翻译成”谁、在什么节点、做什么动作、留下什么记录、记录放在哪里”，让审计人员按图索骥，也让被审计方提前知道要准备什么。
建议清单包含以下字段：
| 字段 | 填写说明 |
|---|---|
| 要求编号 | 与流程文件条款对应，便于回溯依据 |
| 要求描述 | 写成可观察的动作，包含触发条件、执行角色与产出物 |
| 对应过程活动 | 该要求落在哪个阶段、哪个活动上 |
| 责任角色 | 谁负责执行并产出证据 |
| 证据类型 | 计划类、记录类、审批类或结果类 |
| 留存位置 | 记录存放在哪个系统、文档库或归档目录 |
| 抽样方式 | 全量核查还是按比例抽取，抽取口径是什么 |
要求描述最容易出问题。”加强评审””提升文档质量”这类表述无法核验，应改写为可观察动作。例如把”需求变更需规范管理”写成”需求变更提交后，需由产品负责人与测试负责人完成影响评估，评估结论记录在变更单中，并经项目负责人审批后方可进入开发”。这样一条要求就自然对应到变更单、评估记录和审批记录三类证据。
证据类型可按四类区分：计划类如项目计划、测试计划；记录类如评审会议记录、缺陷记录、变更记录；审批类如立项审批、变更审批、发布审批；结果类如测试报告、验收结论、发布记录。分类的意义在于判断证据链是否完整——只有计划没有记录，说明执行环节缺少痕迹；只有结果没有审批，说明决策环节无法追溯。
清单中至少保留一行填写示例，便于各项目组按同一格式准备材料。示例可写成：要求编号 R-04，要求描述”需求变更需完成影响评估并经项目负责人审批”，对应活动”需求变更处理”，责任角色”产品负责人、项目负责人”，证据类型”记录类+审批类”，留存位置”需求管理系统的变更单及审批流”，抽样方式”按变更单数量抽取20%，不少于5条”。
审计执行六步：从抽样到整改复验
六步流程把前面的准备工作串成可执行路径，每一步都应有明确输入、动作、输出和完成标志，避免审计停留在开会和口头确认。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 定范围与依据 | 审计需求、流程文件清单 | 确认项目类型、阶段、团队、时间窗；锁定依据文件版本；确定判定口径 | 审计范围与依据说明 | 审计负责人与过程负责人双方确认 |
| 2. 建证据清单 | 流程文件条款、范围说明 | 逐条拆解要求，填写字段，标注抽样方式 | 证据清单 | 每条要求均有对应活动、角色与留存位置 |
| 3. 确认角色与节点 | 证据清单、项目计划 | 与过程负责人确认证据提供人、提交时间与提交方式 | 角色与节点确认表 | 每个抽样项都有明确的证据提供人和截止时间 |
| 4. 抽样核查 | 证据清单、已提交材料 | 记录比对、人员访谈、系统记录核对三种方式组合使用 | 核查工作底稿 | 每个抽样项均有核查结论和证据位置 |
| 5. 记录结论 | 核查工作底稿 | 按判定口径形成符合性结论，编写不符合项描述 | 审计结论记录 | 结论经审计负责人评审，不符合项要素齐全 |
| 6. 整改与复验 | 不符合项清单 | 责任方制定整改措施，审计方按约定期限复验 | 整改记录与关闭结论 | 全部不符合项完成复验并记录关闭依据 |
第4步的抽样核查建议三种方式组合。记录比对用于确认书面材料是否齐全、要素是否完整；人员访谈用于确认记录之外的实际执行情况，例如询问测试人员是否在每次发布前收到准入结论；系统记录核对用于验证时间戳、审批流和操作痕迹是否与书面记录一致。只依赖书面材料，容易漏掉”记录补做”的情况；只依赖访谈，结论缺乏可追溯依据。
不符合项的描述应包含五个要素：事实（在哪个项目、哪个时间点发现了什么）、依据条款（对应哪份文件的哪条要求）、影响（对过程质量或后续环节的影响）、整改要求（需要补做什么或改什么）、整改期限。缺少依据条款的不符合项容易引发争议，缺少整改期限的则难以闭环。
角色分工与交付物：谁提供证据、谁判定、谁整改
审计中常见的扯皮，是证据没人交、结论没人认、整改没人跟。按角色明确交付物和时点，可以把责任落到具体人身上。
| 角色 | 审计前 | 审计中 | 审计后 |
|---|---|---|---|
| 审计负责人 | 编制范围与依据说明、证据清单，组织启动沟通 | 组织抽样核查，评审核查底稿，判定符合性结论 | 签发审计结论，跟踪整改复验，负责记录归档 |
| 过程负责人（项目经理/技术负责人） | 确认审计范围与节点，指定证据提供人 | 协调材料提交，对存疑事项作说明 | 组织本项目整改，确认整改完成情况 |
| 证据提供人 | 了解清单要求，整理本环节记录 | 按约定时间提交证据，配合访谈与系统核对 | 补充缺失记录，提供整改佐证材料 |
| 整改责任人 | — | 参与不符合项确认，理解整改要求 | 制定并执行整改措施，提交整改证据 |
判定权集中在审计负责人，过程负责人可以对事实认定提出异议，但结论调整需记录理由。审计记录与结论的归档责任也应在启动时明确：由审计负责人统一归档范围说明、证据清单、核查底稿、结论记录和整改关闭材料，形成一次完整审计的可追溯档案。
一个抽样核查示例：需求变更环节怎么审
以”需求变更需经影响评估与审批”这条要求为例，演示从要求到结论的完整链路。
审计人员先从需求管理系统中导出审计时间窗内的变更单清单，按20%比例抽取，不足5条时全量核查，本次抽取6条。对每条变更单，依次核对三项内容：变更单是否记录了影响评估结论，评估是否覆盖对开发排期和测试范围的影响，审批记录是否包含项目负责人且审批时间早于开发启动时间。
记录比对完成后，访谈两位开发人员，确认实际执行中是否存在先开发后补审批的情况。系统记录核对用于验证审批时间戳与变更单状态流转是否一致。
假设核查结果如下：6条变更单中，4条评估与审批记录完整，判定符合；1条有评估记录但缺少项目负责人审批，判定部分符合；1条无任何评估记录且开发已启动，判定不符合。结论记录中需写明每条变更单的编号、证据位置（如变更单链接或归档路径）、判定结果及理由。对不符合项，按事实、依据条款、影响、整改要求、整改期限五要素描述，并指定整改责任人。
这个示例说明，一条要求的审计可以拆成”抽取样本—比对记录—访谈确认—系统核对—形成结论”几个动作，其他环节如设计评审、测试准入、发布审批可以套用同样的链路。
审计完成检查：结论可用性与闭环条件
审计报告提交前，用以下清单逐项确认，判断本次审计是否达到可交付状态。
- 证据覆盖：全部抽样项均有对应证据或明确的不适用说明，每条结论都能定位到具体证据位置。
- 结论一致：判定结果与判定口径表中的定义一致，部分符合与不符合的区分有明确理由。
- 不符合项完整：每个不符合项都写明了事实、依据条款、影响、整改要求和期限，并指定了整改责任人。
- 复验安排明确：复验方式（补充记录核查、现场确认或系统核对）、复验时间和关闭条件已与整改责任人确认。
- 结论边界清晰：报告表述限定在过程符合性与证据充分性范围内，未对产品质量、认证结果或法律责任作出判断。
- 归档完整：范围说明、证据清单、核查底稿、结论记录和整改材料已按统一目录归档。
以上各项全部满足，本次审计可以交付；存在缺项的，应在报告中标注为待补充事项，并说明补充责任人与时间。
用工具承载审计证据链：从要求到整改的状态流转
当审计只涉及一两个项目时，表格和共享文档足以支撑。当审计覆盖多个项目、多个团队，且需要跨季度跟踪整改时，证据的分散存放和状态不同步会成为主要问题：同一份评审记录在多个地方有不同版本，整改任务靠邮件跟进难以确认是否关闭。
一种可行的承载方式是把审计对象结构化。证据清单中的每条要求建成可追踪的工作项，关联到具体项目与阶段，工作项上记录责任角色、证据类型和留存位置；评审记录、审批结论以文档形式与工作项关联，形成”要求—活动—记录—结论”的可追溯链路；核查发现的不符合项转为整改任务，带上整改期限和责任人，跟踪到复验通过后关闭。这样审计负责人可以在一个视图里看到哪些抽样项已核查、哪些不符合项仍在整改、哪些已复验关闭。
ONES 提供工作项与文档管理能力，可用于承载上述证据条目与整改任务的状态流转；其研发管理场景也支持按项目组织需求、任务与评审记录。需要说明的是，具体字段配置、审批流设置和报表视图需以实际产品环境和官方资料为准，本文不展开版本与套餐差异。
工具承载的价值在于让证据链和整改状态可查、可追溯，审计方法本身仍取决于范围是否清晰、要求是否可观察、判定口径是否统一。把这三项做扎实，再选择合适的承载方式，研发过程审计才能从一次性检查变成可重复执行的管理机制。
常见问题
审计时间窗内流程文件改过版，按哪个版本判定？
以被审计活动发生时生效的版本为准，不用改版后的新要求追溯旧项目。如果时间窗跨越改版节点，可在范围说明中分段标注：改版前发生的活动按旧版判定，改版后按新版判定，并在结论记录中写明所依据的文件版本与生效日期。这样同一份审计报告内的判定口径保持一致，也便于被审计方核对。
抽样比例定多少合适，样本不足怎么办？
抽样比例取决于样本总量和风险程度，没有统一数值。常见做法是按业务量抽取一定比例并设最低条数，例如按20%抽取、不少于5条；总量本身不足最低条数时全量核查。对高风险环节（如发布审批、需求变更）可提高比例或全量核查，对记录规范、历史问题少的环节可适当降低。抽样口径应在证据清单中预先写明，执行中不随意调整。
被审计方对不符合项有异议，怎么处理？
先回到事实与依据条款：由过程负责人提交补充证据或说明，审计负责人核对后决定是否调整结论。结论调整需在记录中写明理由和调整依据，保留原判定与新判定的对照。若双方对条款理解本身存在分歧，可提交流程归口部门解释，解释结论作为后续同类判定的参考。异议处理过程本身也应归档，避免复验时重复争议。
整改期限到了但措施没完成，审计怎么收尾？
按未关闭处理，不因期限到期而默认关闭。可在整改记录中标注延期原因、新的完成时间和责任人，并说明是否需要升级到过程负责人的上级。审计报告可以先行交付，但需把未关闭项列为待跟踪事项，明确下一次复验时间。只有复验通过并记录关闭依据后，该项才算闭环。
审计结论能不能用于对外证明研发过程合规？
内部审计结论描述的是本次范围内过程要求与证据的符合情况，适用范围限于抽样项目和时间窗。对外认证、资质审核或法律判断需要由相应机构按各自标准另行评估，内部审计记录可作为过程管理的佐证材料，但不构成认证结论。涉及具体认证资质时，以官方证书和报告原文为准。
