研发过程合规审计通常按审计准备、需求与立项、设计与开发、测试与发布、变更与缺陷、配置与版本、权限与数据、外包与供应商、培训与记录九个阶段展开。每个阶段列出检查内容、通过标准、所需证据、负责人和检查时点，才能在现场逐项核对。清单中还需单独标出阻断项：立项审批缺失、发布记录与版本不一致、变更未评审、关键权限无审批、审计证据无法追溯，任一项未闭环即判定不通过。
要点总览（TL;DR）
- 清单按审计准备、需求与立项、设计与开发、测试与发布、变更与缺陷、配置与版本、权限与数据、外包与供应商等阶段组织，每项写明检查内容、通过标准、所需证据、负责人和检查时点。
- 通过标准要写成可判定的表述，例如“存在经审批的立项记录且审批人可追溯”，避免“流程基本规范”这类无法核对的描述。
- 证据形式按检查项选择：审批类用审批单或系统审批记录，评审类用会议记录和评审结论，执行类用系统日志或执行报告，版本类用版本清单和基线记录。
- 阻断项单独标注：立项审批缺失、发布记录与版本不一致、变更未评审、关键权限无审批、审计证据无法追溯，任一项未闭环即判定不通过。
- 审计结论分通过、有条件通过与不通过三种，完成条件是所有检查项有判定结果、不适用项有原因和确认人、阻断项全部闭环或已有经确认的整改计划。
谁在什么时点使用这份清单
这份清单面向四类角色：研发负责人、项目经理、质量与合规人员、审计配合人。研发负责人关注立项、发布等关键节点的审批是否齐全；项目经理负责整理本项目的过程记录；质量与合规人员负责判定通过标准、识别阻断项；审计配合人负责按证据目录调取材料并安排访谈。四类角色在清单上承担不同的勾选与签字责任，避免现场临时找人补材料。
清单在三个时点使用。审计启动前，由项目经理和研发负责人完成自查，逐项确认证据是否齐备，缺失项在进入现场前补齐。审计现场，质量与合规人员按清单顺序核对证据，审计配合人负责解释和调取系统记录。审计结束后，责任人对未通过项和整改项进行复核，确认闭环后更新清单状态。
| 使用角色 | 启动前自查 | 现场配合 | 整改复核 |
|---|---|---|---|
| 研发负责人 | 确认立项、发布等关键审批 | 解释技术决策与评审结论 | 确认整改措施已落地 |
| 项目经理 | 整理项目过程记录与证据目录 | 按清单调取材料 | 更新整改状态 |
| 质量与合规人员 | 确定抽样项目与判定口径 | 逐项判定通过与否 | 复核闭环证据 |
| 审计配合人 | 确认访谈与现场安排 | 协调人员与系统权限 | 归档最终证据 |
各阶段的输出物不同：审计准备阶段输出范围说明、抽样清单和证据目录；需求与立项、设计与开发、测试与发布等阶段输出逐项判定结果；整改阶段输出整改跟踪表和复核结论。清单本身在审计结束后作为过程记录归档。
审计准备阶段：范围、组织与资料清单
审计准备阶段的目标是在进入现场前把范围、人员和资料确定下来，避免现场反复确认边界。以下检查项应逐项确认。
| 检查项 | 通过标准 | 所需证据 | 负责人 | 时点 |
|---|---|---|---|---|
| 审计范围与项目抽样清单 | 范围说明写明覆盖的项目、时间段和审计边界；抽样清单列明被抽项目及抽样依据 | 范围说明文档、抽样清单 | 质量与合规人员 | 启动前 |
| 审计组织与角色分工 | 每个角色有明确联系人，职责与清单条目对应 | 角色分工表、联系方式 | 研发负责人 | 启动前 |
| 资料清单与证据目录 | 证据目录按阶段和检查项编号，标注证据形式与存放位置 | 证据目录、资料存放路径说明 | 项目经理 | 启动前 |
| 访谈与现场安排 | 访谈对象、时间和议题已确认，系统查询权限已开通 | 访谈日程、权限开通记录 | 审计配合人 | 启动前 |
准备阶段最容易出问题的是证据目录与检查项对不上。建议证据目录直接沿用清单编号，每一项检查对应一个证据条目，现场核对时按编号调取，减少沟通成本。
需求与立项：合规起点检查项
研发起点的合规性决定后续过程能否追溯。立项审批缺失属于阻断项，需要优先确认。
| 检查项 | 通过标准 | 所需证据 | 负责人 | 时点 |
|---|---|---|---|---|
| 立项审批记录 | 存在经审批的立项记录，审批人、审批时间和审批意见可追溯 | 立项审批单或系统审批记录 | 项目经理 | 现场核对 |
| 需求来源与变更依据 | 需求可追溯到来源（业务方、客户或内部规划），需求变更附变更依据 | 需求文档、变更申请单 | 项目经理 | 现场核对 |
| 需求评审记录 | 评审记录包含参与角色、评审结论和遗留问题处理结果 | 评审会议记录、评审结论 | 研发负责人 | 现场核对 |
| 立项与需求文档版本对应 | 立项文档与需求文档的版本号可对应，后续变更保留版本历史 | 文档版本记录、变更历史 | 项目经理 | 现场核对 |
需求评审记录常见的问题是只有会议纪要、没有结论。通过标准应要求写明评审是否通过、遗留问题由谁在什么时间前关闭，这样后续才能判断需求是否具备进入开发的条件。
设计与开发：过程记录检查项
设计与开发阶段检查的是过程记录能否还原技术决策和代码质量把关过程。
| 检查项 | 通过标准 | 所需证据 | 负责人 | 时点 |
|---|---|---|---|---|
| 设计评审记录 | 关键设计有评审记录，评审结论明确，评审意见有处理结果 | 设计文档、评审记录 | 研发负责人 | 现场核对 |
| 代码评审记录与缺陷闭环 | 合并请求有评审人，评审提出的问题有修改记录或关闭说明 | 代码评审记录、问题处理记录 | 开发负责人 | 现场核对 |
| 开发规范执行记录 | 编码规范、分支策略有书面规定，抽查的提交符合规定 | 规范文档、抽查记录 | 开发负责人 | 现场核对 |
| 开发任务与工作项对应 | 开发任务可对应到需求或工作项，任务状态与实际进度一致 | 任务列表、工作项关联记录 | 项目经理 | 现场核对 |
代码评审的检查重点在于问题是否闭环，而非评审数量。抽查时选取若干合并请求，核对评审意见与后续修改是否对应，能直接判断评审是否实际执行。开发任务与工作项的对应关系则用于确认需求到交付的链路完整。
当研发任务、代码评审和需求记录分散在不同工具中时，审计配合人需要花大量时间做人工比对。ONES 提供工作项与文档管理能力，可将需求、任务、评审记录和发布记录放在同一项目空间中关联，便于按项目导出过程记录；其官网展示的认证信息可作为供应商合规资质的参考，具体认证范围与有效期以官方证书为准。
测试与发布：质量门禁检查项
测试与发布阶段检查质量门禁是否被执行，发布记录与版本是否一致。发布记录与版本不一致属于阻断项。
| 检查项 | 通过标准 | 所需证据 | 负责人 | 时点 |
|---|---|---|---|---|
| 测试计划与用例执行记录 | 测试计划覆盖需求范围，用例执行结果有记录，未执行用例有说明 | 测试计划、用例执行报告 | 测试负责人 | 现场核对 |
| 缺陷分级与关闭证据 | 缺陷按约定级别分级，关闭缺陷附验证记录 | 缺陷列表、关闭验证记录 | 测试负责人 | 现场核对 |
| 发布审批与发布记录 | 发布前有审批，发布记录包含版本号、发布时间、发布人和变更内容 | 发布审批单、发布记录 | 项目经理 | 现场核对 |
| 发布版本与测试结论一致 | 发布版本号与测试通过的版本一致，差异有说明 | 版本清单、测试结论 | 测试负责人 | 现场核对 |
发布版本与测试结论不一致是审计中常见的阻断情形，通常源于测试后又有代码合入但未重新验证。检查时以发布记录中的版本号为准，回溯该版本的测试结论，若无法对应则要求补充验证或说明。
变更、缺陷与配置版本检查项
这一阶段检查变更是否经过评审、缺陷能否追溯、配置基线能否还原发布状态。变更未评审属于阻断项。
| 检查项 | 通过标准 | 所需证据 | 负责人 | 时点 |
|---|---|---|---|---|
| 变更申请、评审与批准 | 变更申请写明影响范围，评审记录含参与人和结论，批准人可追溯 | 变更申请单、评审记录、批准记录 | 项目经理 | 现场核对 |
| 缺陷追溯链 | 缺陷从发现、分派、修复到关闭的每个环节有记录，关联到对应版本 | 缺陷记录、版本关联记录 | 测试负责人 | 现场核对 |
| 配置项清单与基线 | 配置项清单完整，基线记录包含基线时间和包含的配置项版本 | 配置项清单、基线记录 | 配置管理员 | 现场核对 |
| 版本发布与基线对应 | 每个发布版本可对应到一条配置基线 | 版本清单、基线对照表 | 配置管理员 | 现场核对 |
变更评审的检查应覆盖紧急变更。紧急变更可以先执行后补评审，但补评审记录必须存在且时间可追溯，否则同样按未评审处理。配置基线检查则关注发布版本能否从基线还原，这是判断证据可追溯性的基础。
权限、数据与外包供应商检查项
权限与外包环节检查的是人员访问是否经过审批、外部人员是否受控。关键权限无审批属于阻断项。
| 检查项 | 通过标准 | 所需证据 | 负责人 | 时点 |
|---|---|---|---|---|
| 关键系统权限申请与审批 | 生产环境、代码仓库等关键系统的权限申请有审批记录，权限范围与岗位匹配 | 权限申请单、审批记录、权限清单 | 系统管理员 | 现场核对 |
| 敏感数据访问与操作日志 | 敏感数据访问有日志，日志保留期限符合内部规定，异常访问有处理记录 | 访问日志、异常处理记录 | 系统管理员 | 现场核对 |
| 外包与供应商资质、协议与交付 | 供应商资质文件在有效期内，协议约定交付物与保密要求，交付记录完整 | 资质文件、协议、交付验收记录 | 采购或项目负责人 | 现场核对 |
| 外部人员权限与离场处理 | 外部人员权限按项目授予，离场后有权限回收记录 | 权限授予记录、离场回收记录 | 系统管理员 | 现场核对 |
权限检查建议以关键系统为线索，抽取若干账号核对申请与审批记录，再核对离场人员的权限回收时间。数据日志检查则关注日志是否覆盖敏感操作、保留时间是否满足内部要求。外包检查的重点是资质有效期和交付验收记录，两者缺一都会影响供应商管理的可追溯性。
通过标准、证据与负责人如何填写
清单能否直接使用，取决于通过标准是否可判定。写法上应包含对象、条件和可观察结果，例如“存在经审批的立项记录且审批人可追溯”，避免“立项流程基本规范”这类无法核对的描述。每条通过标准最好只对应一个判断结论，便于勾选通过或不通过。
证据形式按检查项选择：审批类检查用审批单或系统审批记录；评审类检查用会议记录和评审结论；执行类检查用系统日志、截图或执行报告；版本类检查用版本清单和基线记录。证据需能对应到具体项目和时间点，截图应包含系统名称、时间和操作人信息。
| 字段 | 填写规则 | 示例 |
|---|---|---|
| 检查项 | 写明检查对象和动作 | 发布审批与发布记录 |
| 通过标准 | 可判定，含对象和条件 | 发布前有审批，发布记录含版本号、时间、发布人 |
| 所需证据 | 写明证据形式和存放位置 | 发布审批单、发布记录（项目空间-发布目录） |
| 负责人 | 填写对证据真实性负责的角色 | 项目经理 |
| 检查时点 | 写明自查、现场或复核 | 现场核对 |
| 不适用标注 | 写明不适用原因和确认人 | 不适用：本项目无外包，确认人：项目经理 |
不适用项不能留空。填写时应写明原因并由确认人签字，避免现场被误判为缺项。负责人填写对证据真实性负责的角色，而非材料整理人，这样整改时能找到对应责任人。
阻断项与审计完成条件
阻断项是判定不通过的直接依据，需要在清单中单独标注，并在审计结论中逐项说明闭环情况。
| 阻断项 | 闭环判定方式 |
|---|---|
| 立项审批缺失 | 补充审批记录且审批时间可追溯，或提供等效的决策记录并经审计确认 |
| 发布记录与版本不一致 | 补充版本对应说明和验证记录，确认发布版本经过测试验证 |
| 变更未评审 | 补充评审记录，紧急变更需有事后评审记录和时间戳 |
| 关键权限无审批 | 补充权限审批记录，或提供权限回收和重新授予的记录 |
| 审计证据无法追溯 | 补充可对应到项目、版本和时间点的证据，或提供系统日志佐证 |
审计结论分三种。全部检查项通过且无阻断项，判定通过。存在一般项未通过但无阻断项，或阻断项已制定整改计划并经审计确认，判定有条件通过，整改完成后复核。任一阻断项未闭环，判定不通过。整改复核时以阻断项闭环证据为准，复核人签字后清单状态更新为完成。
审计完成的条件是：所有检查项有明确判定结果，不适用项有原因和确认人，阻断项全部闭环或有经确认的整改计划，最终证据按目录归档。满足这些条件后，清单可作为本次研发过程合规审计的过程记录留存。
常见问题
审计现场发现证据缺失，是当场判定不通过还是先记录待补？
先区分缺失项的性质。属于阻断项的，例如立项审批缺失、关键权限无审批，应当场记录并进入阻断项判定流程，不能以“后续补交”直接视为通过。属于一般项的，可记录为待补，由责任人在约定时间内提交，审计配合人核对后更新判定结果。无论哪种情况，缺失事实和补交时间都应写入清单备注，避免审计结束后无法还原当时的判定依据。
紧急变更先上线后补评审，审计时怎么认定？
紧急变更允许先执行后补评审，但补评审记录必须存在，且时间戳能证明评审在变更后合理时间内完成。检查时核对变更申请、执行时间和补评审时间三者是否连贯，评审结论是否明确。若补评审记录缺失或时间无法追溯，按变更未评审处理，属于阻断项。建议在清单中为紧急变更单独留一列，记录补评审时间，便于现场快速判断。
项目没有外包和外部人员，相关检查项怎么填？
不适用项不能留空，应写明不适用原因并由确认人签字，例如“不适用：本项目无外包，确认人：项目经理”。这样现场核对时不会被误判为缺项，也保留了判定痕迹。若项目部分环节涉及外部人员，例如短期驻场开发，则按实际范围填写权限授予和离场回收记录，不整体标注不适用。
审计结束后整改项复核，需要重新走一遍全部检查项吗？
不需要全量重走。复核以未通过项和阻断项的闭环证据为重点，核对整改措施是否落地、证据是否可追溯。一般项整改完成后更新状态即可；阻断项需复核人确认闭环证据并签字，清单状态才更新为完成。若整改涉及发布版本或配置基线变更，应同时核对版本与基线对应关系是否仍然成立。
用工具承载审计证据时，需要关注哪些方面？
重点看三件事：过程记录能否按项目关联，需求、任务、评审和发布记录是否在同一处可查；证据能否导出并对应到具体时间点；权限与操作日志是否可追溯。ONES 提供工作项与文档管理能力，可将需求、任务、评审记录和发布记录放在同一项目空间中关联；其官网展示的可信云、CMMI3、ISO、等保三级等认证信息可作为供应商合规资质的参考，具体认证范围与有效期以官方证书为准。
