研发审计证据清单用来把散落在评审、测试、变更和审批环节的记录整理成可核查的条目，核心字段包括证据编号、审计事项与控制要求、研发阶段、证据类型、名称与存放位置、产生时间、责任人与确认人、版本标识、完整性与保密级别、留存期限和复核结论。下面先给一份可直接复制使用的空白表，再逐字段说明填写口径、必填与选填的划分、一条完整记录的写法，以及清单随项目调整时的维护方法。
要点总览（TL;DR）
- 清单以“一条证据一行”组织，核心字段包括证据编号、审计事项与控制要求、研发阶段、证据类型、名称与存放位置、产生时间、责任人与确认人、版本标识、完整性、保密级别、留存期限和复核结论。
- 证据编号、审计事项、控制要求、研发阶段、证据类型、证据名称、存放位置、产生时间、责任人和复核结论为必填，缺任一项即判定证据不可用。
- 所属周期、保密级别、留存期限可作选填；版本/提交标识、确认人、完整性在涉及代码、文档版本或需签字确认时必填。
- 复核结论写“可用”“待补”或“不可用”并附一句依据，待补项设定期限，便于后续复查。
- 清单需按项目类型裁剪选填字段、递增版本号保留历史记录，并按审计周期复核路径与留存期限。
可复制空白模板：研发审计证据清单表
清单由封面信息区和明细表两部分组成。封面固定本次审计的范围与版本，明细表按“一条证据一行”展开。复制到表格工具后，先填封面，再逐行登记证据。
封面信息区
| 封面项 | 填写内容 |
|---|---|
| 清单名称 | 如“XX系统V2.0研发过程审计证据清单” |
| 审计范围 | 涉及的项目、版本、研发阶段区间 |
| 审计周期 | 起止日期，或对应的迭代/里程碑区间 |
| 编制人 / 日期 | 姓名与编制日期 |
| 审核人 / 日期 | 姓名与审核日期 |
| 清单版本 | 如V1.0、V1.1，每次修订递增 |
| 证据总条数 | 明细表行数汇总 |
明细表（空白）
| 证据编号 | 审计事项 | 控制要求 | 研发阶段 | 证据类型 | 证据名称 | 存放位置 | 产生时间 | 所属周期 | 责任人 | 确认人 | 版本/提交标识 | 完整性 | 保密级别 | 留存期限 | 复核结论 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
行数按实际证据数量增减，编号连续，不留空行。若一条控制要求对应多份证据，拆成多行分别登记，便于逐份核对。
字段说明：每个字段记录什么、按什么口径填
同一份清单可能由多人填写，字段口径统一才能横向比对。下表给出每个字段的含义、填写方式和示例值。
| 字段 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 证据编号 | 清单内唯一标识 | “项目代号-阶段码-序号”，阶段码可用RQ/DS/DEV/TEST/REL，序号三位递增 | CRM-DEV-007 |
| 审计事项 | 该证据支撑的审计检查点 | 用一句可判断的表述，指向具体控制活动 | 代码变更须经同行评审 |
| 控制要求 | 制度或流程中对应的条款 | 引用制度名称与条款号，无条款号时写要求原文摘要 | 《研发变更管理规范》第4.2条 |
| 研发阶段 | 证据产生的阶段 | 从需求、设计、开发、测试、发布、运维中选一，跨阶段证据填产生时所在阶段 | 开发 |
| 证据类型 | 证据的类别 | 评审记录、测试报告、变更记录、审批单据、会议纪要、配置基线、培训记录等，按统一词表取值 | 变更记录 |
| 证据名称 | 证据本身的标题 | 与文件或记录标题一致，不加自拟描述 | 订单模块支付接口变更评审单 |
| 存放位置 | 证据的检索路径 | 写清系统/目录/文档库路径或工作项编号，保证他人可按路径直接打开 | 文档库/研发/变更记录/2024Q2/CR-0231 |
| 产生时间 | 证据形成日期 | 精确到日，与文件内落款一致 | 2024-05-16 |
| 所属周期 | 证据归属的迭代或里程碑 | 写迭代号或里程碑名称，便于按周期汇总 | 迭代Sprint 12 |
| 责任人 | 证据的产出或保管人 | 填实际执行该活动的角色与姓名 | 开发负责人 张明 |
| 确认人 | 对证据有效性签字确认的人 | 填评审人、测试负责人或质量人员，与责任人分开 | 质量工程师 李倩 |
| 版本/提交标识 | 证据对应对象的版本 | 文档写版本号，代码写提交号或标签，测试写报告版本 | commit a3f9c21 / 文档V1.2 |
| 完整性 | 证据是否齐全 | 填“完整”“缺附件”“缺签字”等状态，并注明缺项 | 完整 |
| 保密级别 | 证据的访问范围 | 按组织分级填写，如公开、内部、受限 | 内部 |
| 留存期限 | 证据需保存的时长 | 依据制度或合同约定填写，注明起算点 | 自发布起3年 |
| 复核结论 | 复核后的判定 | 填“可用”“待补”“不可用”，并简述理由 | 可用 |
编码规则建议在清单封面注明，后续新增证据沿用同一规则。控制要求与研发阶段的对应关系要能互相印证：阶段填“开发”，控制要求应指向开发期活动，出现错位时先核对证据归属再修改。
必填与选填：哪些字段缺失会导致证据不可用
字段取舍直接影响证据能否被审计人员采信。缺少关键字段的记录无法定位或无法证明其有效性，应按不可用处理；信息暂缺但可补齐的，标记为待补并限期补全。
| 档位 | 字段 | 缺失后果与处理 |
|---|---|---|
| 必填 | 证据编号、审计事项、控制要求、研发阶段、证据类型、证据名称、存放位置、产生时间、责任人、复核结论 | 缺任一项即无法定位或无法判断有效性，判定为证据不可用，需重新收集 |
| 选填 | 所属周期、保密级别、留存期限 | 不影响单条证据成立；清单整体归档时建议补齐，便于汇总与到期清理 |
| 条件必填 | 版本/提交标识、确认人、完整性 | 涉及代码、文档版本或需签字确认的场景必填；涉及变更、外包、外部依赖时，还应在审计事项中注明变更单号或供应商名称 |
判定“待补”与“不可用”的界线可以这样把握：证据本体存在、路径可打开，仅个别字段待完善，记为待补；证据本体缺失、路径失效或无法证明对应控制活动已执行，记为不可用。待补项应设定补全期限，并在复核结论中保留原始判定记录。
填写示例：一条完整证据记录怎么填
以下示例为演示情景，展示一条变更类证据的完整填法，各字段取值与上文字段说明保持一致。
| 字段 | 填写内容 |
|---|---|
| 证据编号 | CRM-DEV-007 |
| 审计事项 | 代码变更须经同行评审 |
| 控制要求 | 《研发变更管理规范》第4.2条 |
| 研发阶段 | 开发 |
| 证据类型 | 变更记录 |
| 证据名称 | 订单模块支付接口变更评审单 |
| 存放位置 | 文档库/研发/变更记录/2024Q2/CR-0231 |
| 产生时间 | 2024-05-16 |
| 所属周期 | 迭代Sprint 12 |
| 责任人 | 开发负责人 张明 |
| 确认人 | 质量工程师 李倩 |
| 版本/提交标识 | commit a3f9c21 |
| 完整性 | 完整 |
| 保密级别 | 内部 |
| 留存期限 | 自发布起3年 |
| 复核结论 | 可用：评审单含两名评审人签字，提交号与变更单一致 |
清单片段中，相邻两行可以分别登记同一变更的评审单与上线审批单，编号连续（CRM-DEV-007、CRM-DEV-008），审计事项分别对应“变更须评审”和“上线须审批”。复核结论栏写判定加一句依据，便于后续复查时快速理解当时为何认定可用。
调整与维护：按项目类型裁剪字段并保持清单可用
清单不是一次填完就固定不变。项目类型、审计周期和证据存放方式变化时，需要同步调整字段与记录，保持清单与证据实际状态一致。
按项目类型裁剪
硬件或嵌入式项目可增加样机测试、物料认证类证据类型；纯软件项目可省略物料相关字段。外包比例高的项目，在审计事项中固定增加供应商与交付验收信息。裁剪只针对选填字段和证据类型词表，必填字段保持不动，避免不同项目清单无法汇总。
版本更新与历史记录保留
每次修订封面版本号递增，并在修订说明中记录改了哪些字段、为什么改。旧版本清单单独归档，不覆盖原文件，保证审计时能追溯某一时点的清单状态。
周期性复核与失效证据清理
按审计周期或季度对清单做一次复核：核对存放位置是否仍可打开，版本标识是否与当前基线一致，留存期限到期的证据按制度处理并在清单中标注。失效路径及时更新，无法恢复的证据改判为不可用并说明原因。
清单与证据存放位置同步
证据在研发管理工具中产生时，评审记录、测试报告和变更记录通常依附于工作项或文档。以ONES为例，工作项的状态流转和文档版本会留下操作记录，清单的“存放位置”可直接填写工作项编号或文档路径，复核时按编号回到原记录核对，减少路径失效带来的返工。工具承载的是留痕与检索，证据是否满足控制要求仍由复核人判断。
维护动作落到日常，可以在每次迭代结束前更新当周期证据行，在里程碑评审时集中复核一次，把清单版本、证据路径和复核结论作为同一份交付物归档。
常见问题
证据清单里的“复核结论”由谁填写，和“确认人”有什么区别？
确认人是对证据有效性签字确认的人，通常是评审人、测试负责人或质量人员，属于证据产生环节的角色；复核结论是清单汇总后由审计或质量复核人员填写的判定，回答“这份证据能否支撑对应控制要求”。两者可以由同一人承担，但建议在清单中分开记录，避免把证据产生时的确认与清单复核混为一谈。复核结论应写判定加一句依据，例如“可用：评审单含两名评审人签字，提交号与变更单一致”。
项目进行中证据还没产生，清单应该先空着还是先登记？
建议先按控制要求登记计划中的证据行，证据编号、审计事项、控制要求、研发阶段、证据类型和责任人先填，存放位置、产生时间和复核结论留空，复核结论暂记“待补”并注明预计产生时间。这样清单同时承担证据台账和缺口提醒的作用。证据产生后再补全路径与时间，复核后改为“可用”。若到审计时点仍未产生，则按不可用处理并说明原因。
同一份证据支撑多条控制要求，需要重复登记吗？
按“一条证据一行”的原则，同一份证据只登记一行，在审计事项和控制要求栏列出它支撑的全部检查点，用分号分隔。若不同控制要求对应的复核人不同，或需要分别判定可用性，则拆成多行登记，并在证据编号上做区分，例如同一文件用“CRM-DEV-007-1”“CRM-DEV-007-2”。拆分与否以复核和追溯是否方便为准，不建议为了凑行数重复登记同一份文件。
证据存放在研发管理工具里，存放位置字段怎么写才不容易失效？
优先写稳定标识而不是完整文件路径：工作项写项目代号加工作项编号，文档写文档库中的固定路径加文档标题，代码写仓库名加提交号或标签。完整路径在目录调整后容易失效，编号和提交号相对稳定。若证据依附于工作项的状态流转记录，可在存放位置注明工作项编号，复核时按编号回到原记录核对操作留痕。清单维护时定期抽查路径是否仍可打开，失效的及时更新或改判。
留存期限应该按什么依据填写，到期后证据怎么处理？
留存期限依据组织制度、合同约定或项目所属行业的内部管理要求填写，并注明起算点，例如“自发布起3年”“自项目验收起5年”。清单本身不提供法定留存年限，具体期限需由合规或质量部门确认。到期证据按制度执行销毁或归档，并在清单中标注处理日期与处理方式，保留处理记录，避免到期后直接删除导致无法说明证据去向。
