研发过程审计证据目录用来把散落在需求、设计、代码、测试、发布等环节的记录整理成可追溯的清单。本文提供一份可直接复制到表格工具的空白模板，并说明字段填写口径、必填与选填的取舍、七类应准备的材料，以及一条完整记录的填写示例，帮助研发或质量岗位在审计准备阶段快速建立目录。
要点总览（TL;DR）
- 证据目录按“一条证据一行”组织，核心字段包括证据编号、审计检查项、研发阶段、材料名称、材料类型、存放位置、责任人、形成日期、版本标识、获取方式、完整性状态、密级与备注。
- 无论审计强度如何，编号、检查项、材料名称、存放位置、责任人和形成日期六项应保留，它们构成定位原始记录的最小追溯要素。
- 材料按需求与立项、设计与评审、开发与代码、测试与缺陷、发布与变更、配置与基线、问题与整改七类归集，每类优先保留原始记录或注明导出信息的系统导出件。
- 目录需随项目进展定期补充和更新版本，材料移动后同步修改存放位置，审计结束后连同原始材料一并归档，便于下一轮复用。
可复制空白证据目录模板
下表按“一条证据一行”组织，表头覆盖证据编号、审计检查项、对应研发过程/阶段、证据材料名称、材料类型、产生系统或存放位置、责任人与所属部门、形成日期、版本或标识、获取方式、完整性状态、密级与访问权限、备注。使用时将示例占位行替换为实际记录，同一检查项需要多份材料时拆成多行，不要在一行内堆叠多个材料名称。
| 证据编号 | 审计检查项 | 对应研发过程/阶段 | 证据材料名称 | 材料类型 | 产生系统或存放位置 | 责任人 | 所属部门 | 形成日期 | 版本或标识 | 获取方式 | 完整性状态 | 密级与访问权限 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EV-001 | （填写检查项） | 需求与立项 | （填写材料名称） | （原始记录/系统导出件/评审纪要等） | （系统名称或目录路径） | （填写姓名） | （填写部门） | YYYY-MM-DD | （版本号或文件标识） | （系统导出/截图/原件调取） | （完整/部分缺失/待补充） | （密级/可访问范围） | （补充说明） |
| EV-002 | （填写检查项） | 设计与评审 | （填写材料名称） | （原始记录/系统导出件/评审纪要等） | （系统名称或目录路径） | （填写姓名） | （填写部门） | YYYY-MM-DD | （版本号或文件标识） | （系统导出/截图/原件调取） | （完整/部分缺失/待补充） | （密级/可访问范围） | （补充说明） |
| EV-003 | （填写检查项） | 开发与代码 | （填写材料名称） | （原始记录/系统导出件/评审纪要等） | （系统名称或目录路径） | （填写姓名） | （填写部门） | YYYY-MM-DD | （版本号或文件标识） | （系统导出/截图/原件调取） | （完整/部分缺失/待补充） | （密级/可访问范围） | （补充说明） |
| EV-004 | （填写检查项） | 测试与缺陷 | （填写材料名称） | （原始记录/系统导出件/评审纪要等） | （系统名称或目录路径） | （填写姓名） | （填写部门） | YYYY-MM-DD | （版本号或文件标识） | （系统导出/截图/原件调取） | （完整/部分缺失/待补充） | （密级/可访问范围） | （补充说明） |
| EV-005 | （填写检查项） | 发布与变更 | （填写材料名称） | （原始记录/系统导出件/评审纪要等） | （系统名称或目录路径） | （填写姓名） | （填写部门） | YYYY-MM-DD | （版本号或文件标识） | （系统导出/截图/原件调取） | （完整/部分缺失/待补充） | （密级/可访问范围） | （补充说明） |
| EV-006 | （填写检查项） | 配置与基线 | （填写材料名称） | （原始记录/系统导出件/评审纪要等） | （系统名称或目录路径） | （填写姓名） | （填写部门） | YYYY-MM-DD | （版本号或文件标识） | （系统导出/截图/原件调取） | （完整/部分缺失/待补充） | （密级/可访问范围） | （补充说明） |
| EV-007 | （填写检查项） | 问题与整改 | （填写材料名称） | （原始记录/系统导出件/评审纪要等） | （系统名称或目录路径） | （填写姓名） | （填写部门） | YYYY-MM-DD | （版本号或文件标识） | （系统导出/截图/原件调取） | （完整/部分缺失/待补充） | （密级/可访问范围） | （补充说明） |
表格可直接复制到 Excel、在线表格或文档中。阶段列已按七类过程给出占位行，实际使用时按项目删减或增行，保持同一阶段内证据编号连续，便于审计人员按阶段翻阅。
证据目录字段说明与填写口径
字段设计的目标是让审计人员仅凭目录就能定位到原始记录，并判断该记录是否覆盖检查项。下表逐字段说明含义、取值方式和常见错误。
| 字段 | 定义与填写口径 | 常见填写错误 |
|---|---|---|
| 证据编号 | 目录内唯一标识，建议采用“项目代号-阶段代码-序号”，如 PRJ01-REQ-001；阶段代码可用 REQ、DES、DEV、TST、REL、CFG、FIX 分别对应七类过程 | 编号重复、跨项目复用同一编号、中途改号导致与已提交材料对不上 |
| 审计检查项 | 引用审计方给出的检查项编号或原文描述，保持与审计清单措辞一致 | 自行改写检查项，导致审计人员无法对应 |
| 对应研发过程/阶段 | 从需求与立项、设计与评审、开发与代码、测试与缺陷、发布与变更、配置与基线、问题与整改中选择 | 一份材料跨多个阶段时只填一个阶段，遗漏其他阶段的覆盖关系 |
| 证据材料名称 | 材料的正式名称，与文件标题或系统记录标题一致 | 写成“相关文档”“测试记录”等笼统描述 |
| 材料类型 | 区分原始记录、系统导出件、评审纪要、审批单、截图、日志等；导出件应注明导出时间 | 把截图当作原始记录，或导出件未标注导出时间与导出人 |
| 产生系统或存放位置 | 材料最初产生的系统（如需求管理、代码托管、缺陷跟踪、CI 流水线）或归档目录路径 | 只写“共享盘”，未给到可定位的目录层级 |
| 责任人 | 对该材料真实性负责的具体人员，通常是记录创建人或阶段负责人 | 填写部门名称代替人名，出问题时无法追溯 |
| 所属部门 | 责任人所在部门，用于判断职责分离与审批链 | 与责任人混填，或填写项目组简称导致无法对应组织架构 |
| 形成日期 | 材料实际产生日期，格式统一为 YYYY-MM-DD | 填写导出日期或提交审计的日期，掩盖记录形成时间 |
| 版本或标识 | 文档版本号、提交哈希、构建号、工单号等能唯一定位该份材料的标识 | 只写“最新版”，材料更新后无法还原审计时点的内容 |
| 获取方式 | 系统导出、截图、原件调取、邮件调取等，并注明由谁执行 | 未记录获取人，导出件来源无法复核 |
| 完整性状态 | 可选值建议为：完整、部分缺失、待补充、不适用；部分缺失时在备注写明缺哪部分 | 全部填“完整”，缺失项在审计现场才暴露 |
| 密级与访问权限 | 标注材料密级及可访问范围，如内部、项目组、审计组只读 | 留空导致敏感材料被无关人员调阅 |
| 备注 | 记录缺失原因、替代材料、补充计划等 | 把关键说明写进其他字段，备注留空 |
材料类型与产生系统存在常见对应关系：需求条目和立项审批通常来自需求管理或项目管理工具；设计文档与评审结论来自文档协作平台和评审记录；代码提交、合并请求来自代码托管系统；测试用例执行与缺陷记录来自测试管理或缺陷跟踪系统；发布单与变更审批来自发布或变更管理流程；配置项与基线来自配置管理库；问题与整改记录来自问题跟踪或审计整改台账。填写时以材料实际产生位置为准，不强行套用对应关系。
必填与选填字段的划分
字段取舍取决于审计强度。内部例行审计可以精简，外部认证审核或监管检查通常要求更完整的追溯链。无论哪种强度，编号、检查项、材料名称、存放位置、责任人、形成日期这六项都应保留，它们构成定位原始记录的最小要素。
| 字段 | 建议属性 | 理由与适用情形 |
|---|---|---|
| 证据编号 | 必填 | 目录检索与交叉引用的基础，任何强度都不可省 |
| 审计检查项 | 必填 | 建立证据与审计要求的对应关系 |
| 对应研发过程/阶段 | 必填 | 支撑按阶段核查过程完整性 |
| 证据材料名称 | 必填 | 识别材料本身 |
| 产生系统或存放位置 | 必填 | 审计人员据此调阅原件 |
| 责任人 | 必填 | 材料真实性与补充责任的落脚点 |
| 形成日期 | 必填 | 判断记录是否在过程发生时形成 |
| 材料类型 | 建议必填 | 外部审核常要求区分原始记录与导出件；内部轻量审计可并入备注 |
| 所属部门 | 建议必填 | 涉及职责分离检查时必填，小团队内部审计可省略 |
| 版本或标识 | 选填 | 材料会持续更新、需要还原审计时点内容时填写；一次性归档材料可省略 |
| 获取方式 | 选填 | 存在系统导出件时建议填写，便于复核来源 |
| 完整性状态 | 选填 | 证据尚未收齐、需要跟踪补充进度时填写 |
| 密级与访问权限 | 选填 | 材料涉及敏感信息或需控制调阅范围时填写 |
| 备注 | 选填 | 用于记录缺失原因、替代材料与补充计划 |
裁剪模板时，可以合并“所属部门”到责任人栏、把“获取方式”写入备注，但不要删除编号、检查项、材料名称、存放位置、责任人和形成日期。审计强度提高时，优先补回材料类型、版本或标识、获取方式三项，它们直接决定导出件能否被复核。
研发过程审计需要准备的材料清单
材料按七类过程归集，每类至少保留可追溯的原始记录或系统导出件。下表列出常见材料类型及归集要点，实际项目可按研发模式增删。
| 过程类别 | 常见证据材料 | 归集要点 |
|---|---|---|
| 需求与立项 | 需求条目及变更记录、立项申请与审批单、项目计划、范围说明 | 保留审批人与审批时间；需求变更保留变更前后版本 |
| 设计与评审 | 架构与详细设计文档、评审通知与评审纪要、评审问题关闭记录 | 评审纪要需有参与人、结论和待办项；设计变更同步更新版本 |
| 开发与代码 | 代码提交记录、合并请求与代码评审意见、编码规范检查结果 | 以提交哈希或合并请求编号定位；评审意见与修改记录成对保留 |
| 测试与缺陷 | 测试计划、测试用例与执行记录、缺陷单及修复验证记录、测试报告 | 执行记录需体现执行人、时间与结果；缺陷关闭需有验证人 |
| 发布与变更 | 发布申请与审批、变更单、发布记录、回滚预案与执行记录 | 发布内容与构建号对应；紧急变更保留事后补审批记录 |
| 配置与基线 | 配置项清单、基线建立与变更记录、配置审计记录 | 基线变更需有审批；配置项与代码、文档版本可对应 |
| 问题与整改 | 审计或检查发现的问题清单、整改计划、整改完成证明、复盘记录 | 问题与整改记录一一对应；完成证明需可核验 |
系统导出件应注明导出时间、导出人和导出范围，并与原始系统记录保持可核对关系。纸质签字材料可扫描留存，同时在目录中记录原件存放位置。
填写示例：一条完整证据记录
以下示例演示一条记录如何把字段配合使用。示例为演示情景，项目名称与人员为虚构。
| 字段 | 填写内容 |
|---|---|
| 证据编号 | PRJ01-DES-003 |
| 审计检查项 | 检查项 2.3：设计文档是否经过正式评审并形成结论 |
| 对应研发过程/阶段 | 设计与评审 |
| 证据材料名称 | 订单服务详细设计评审纪要（V1.2） |
| 材料类型 | 评审纪要（原始记录） |
| 产生系统或存放位置 | 文档协作平台 / 研发部 / PRJ01 / 设计评审目录 |
| 责任人 | 张明（设计负责人） |
| 所属部门 | 研发一部 |
| 形成日期 | 2025-03-14 |
| 版本或标识 | V1.2，评审单号 RV-20250314-02 |
| 获取方式 | 文档平台导出 PDF，由质量岗李华于 2025-06-02 导出 |
| 完整性状态 | 完整 |
| 密级与访问权限 | 内部，审计组只读 |
| 备注 | 评审提出的 3 项问题已在同目录关闭记录中体现 |
这条记录中，编号体现项目与阶段，检查项引用审计清单原文，材料名称与版本标识能定位到具体评审单，获取方式说明导出人与时间，备注指向问题关闭记录，形成完整的追溯链。若该评审纪要缺少参与人签字，完整性状态应改为“部分缺失”，并在备注写明补充计划。
证据目录的调整与维护方法
证据目录在项目周期内会持续变化，需要按固定规则维护，避免审计时目录与材料脱节。
- 按项目类型调整字段。涉及外部认证的项目保留材料类型、版本或标识、获取方式；内部小规模项目可精简所属部门与密级字段，但保留六项最小追溯要素。
- 定期补充与更新版本。在里程碑或迭代结束时核对目录，新增证据及时登记；材料更新时新增一行并标注新版本，保留旧版本记录，不直接覆盖。
- 目录与存放位置同步。材料移动或系统迁移后，同步修改存放位置字段；建议每月抽查若干条记录，确认按目录路径能调取到原件。
- 归档与复用。审计结束后将目录与原始材料一并归档，标注审计批次与日期；同类项目的下一轮审计可复用表头与阶段分组，替换项目代号后重新编号。
当研发过程记录本身在工具中产生，目录维护可以与记录管理同步进行。例如在 ONES 中，需求、任务、缺陷、测试用例和评审记录以工作项和文档形式留存，阶段状态与责任人随流程更新，准备审计时可按项目筛选并导出对应记录，再登记到证据目录的存放位置与版本字段，减少目录与系统记录不一致的情况。ONES 公开资料列有可信云、CMMI3、ISO 系列、等保三级等认证信息，具体认证范围与有效期需向厂商核实，本文不据此作出合规结论。
常见问题
内部例行审计和外部认证审核，证据目录的字段可以一样吗？
可以共用同一套表头，但字段取舍不同。内部例行审计可精简所属部门、密级与访问权限等字段，保留编号、检查项、材料名称、存放位置、责任人和形成日期六项最小追溯要素即可。外部认证审核或监管检查通常要求更完整的追溯链，建议补回材料类型、版本或标识、获取方式，并保留所属部门以支撑职责分离检查。裁剪时把省略字段的信息并入备注，避免追溯链断裂。
同一份材料同时覆盖多个审计检查项，目录里要重复登记吗？
建议按检查项拆行登记，每行对应一个检查项，证据编号保持唯一，并在备注中注明与其他行的关联关系。这样审计人员按检查项翻阅时能直接定位到材料，不会因为一行堆叠多个检查项而漏看。如果材料完全相同且检查项措辞接近，也可合并为一行并在检查项栏列出多个编号，但需确保每个编号都能在目录中检索到。
系统导出件作为证据时，目录里需要额外记录什么？
系统导出件应在材料类型中注明“系统导出件”，在获取方式中记录导出人、导出时间和导出范围，在版本或标识中填写能定位导出时点内容的标识，如构建号、工单号或导出批次号。导出件与原始系统记录之间应保持可核对关系，必要时在备注中说明核对方式。若导出件经过格式转换或截图处理，需在备注中说明处理方式，避免审计人员误认为是原始记录。
证据目录建好后，材料在系统里更新了版本，目录怎么处理？
材料更新时建议新增一行并标注新版本，保留旧版本记录，不直接覆盖原行。在备注中注明新旧版本的替代关系，完整性状态按实际情况调整。这样审计时既能还原旧时点的内容，也能看到版本演进过程。如果更新频繁，可在目录中增加“是否当前有效版本”的辅助列，或在备注中统一标注，避免目录行数过多影响翻阅。
研发过程记录本身在工具中产生，证据目录还需要手工维护吗？
需要保留目录作为审计索引，但维护方式可以借助工具减少重复劳动。当需求、任务、缺陷、测试用例和评审记录在 ONES 中以工作项和文档形式留存时，准备审计可按项目筛选并导出对应记录，再登记到证据目录的存放位置与版本字段，降低目录与系统记录不一致的概率。目录本身仍建议保留，因为它承担跨系统汇总和审计检查项对照的职责，系统记录无法完全替代。
