合规人员最常卡的不是「要不要审」，而是审起来发现范围说不清、材料收不全、结论写不出。这篇按执行顺序给一条能照着走的流程：从划定审计范围和系统清单开始，到资料调取与访谈、问题定级、报告归档，每步都给出产出物和留证要求。涉及技术侧的边界口径，正文会指向站内已有文章，不重复讲原则。判断标准是通用的，具体多少条、多久一轮要看你们自己的制度和监管口径。
合规人员最常卡的不是「要不要审」，而是审起来发现范围说不清、材料收不全、结论写不出。真按执行顺序走一遍，很多麻烦其实在立项阶段就注定了：范围开太大后面收不回，证据来源没记清后面没法复现，问题只写现象不写依据后面整改推不动。
这篇给一条能照着走的流程：划定审计范围和系统清单、资料调取与访谈、问题定级、报告与归档，每步都给出产出物和留证要求。具体审多少条、多久一轮，要看你们自己的制度、业务体量和适用监管口径，这里只给通用判断标准。涉及技术侧的边界口径，站内已有文章讲过，正文只指路不重复。
第一步：定范围、立项目、拉系统清单
范围先写死。切入口有三个：按业务线切、按系统切、按数据处理环节切。第一次审建议挑一个切口，比如只审面向 C 端的收集与告知环节，别一上来铺全公司。铺太大最典型的结果是访谈排不下、材料收不完，审到一半自己先停摆。
什么情况下这一步不适用？如果团队刚成立，还没有成型的处理活动记录，也没有可对照的内部制度，那你要做的其实是资产盘点而不是审计。盘点先回答「有哪些处理活动、谁在管、存哪」，等台账成形了再进审计流程。
- 写审计目的与依据一句话交代这次要回答什么问题，再列判定时引用的内部制度和适用规则清单。目的是后面定级的锚，写得模糊会导致同样一条问题两次定级不一致。
- 定审计组与分工组里必须有人能对问题定性拍板，通常是合规负责人或法务负责人。分工写清楚谁访谈、谁收材料、谁出报告，不然每条问题都会被业务来回拉扯。
- 拉系统台账按收集、存储、使用、共享、删除逐环节标注每个系统落在哪一环。标不出来的位置就是第一批待查项，比凭空列问题清单靠谱得多。
- 产出物一：审计范围说明，写明覆盖哪些业务、系统、时间段，以及明确排除在外的部分
- 产出物二：审计组成员与分工表，标注谁有定性决策权
- 产出物三：系统台账，按处理环节标注归属
- 留证要求：这三份材料都要有版本和确认人，后续所有取证都挂在这两张表上
第二步：调资料、做访谈、把证据固定下来
资料调取按四类给清单：制度文件、流程记录、系统配置与日志、对外协议与告知文本。每份材料都要记来源、版本、取得时间、提供人。缺版本号的材料不是不能用，但要标注不确定性，别在报告里当成铁证。
访谈对象别只找法务和 IT。业务操作岗才是决定流程真跑没跑的关键。同一件事至少找两个角色交叉问，两边说法对不上的地方，基本就是高风险点，值得单独列出来深挖。
电子证据留存的核心是能复现。截图要带上时间信息和操作账号，导出的表格保留原始字段，不要手工二次加工后再存档——加工过的表在复核时没法证明它和系统里一致。链路和日志口径怎么判定，站内已有数据边界审计的文章讲透了，这里只负责把证据收进档案。
- 证据清单编号，每条证据对应一条待查事项，避免收一堆没法对应的问题
- 访谈记录当场确认，口述内容让被访谈人过一眼再归档
- 材料缺失不等于没问题，缺失本身要作为一条发现记下来
- 同一事实有多份材料时，以能对应到系统实测的那份为准
第三步：问题定级，写清「事实—依据—影响」
每条问题按三段式写：客观事实（在哪、什么状态）、依据条款（内部制度或适用规则）、可能影响（对个人权益或业务的具体面）。缺任何一段都会被业务一句「这不算问题」驳回。事实段只写能验证的东西，别掺判断词。
定级用两到三档就够，比如立即整改、限期整改、观察项。档位依据写清是影响范围大、还是根本没有控制措施，别把主观严重程度当唯一标准。人数少但敏感度高的场景同样可能进最高档，反过来量大但已有限制的未必进最高档。
有一种情况要单独处理：如果制度本身还没建立，就不要按「违反制度」定级，而是作为制度缺失项单列。混在一起定级，整改责任人会顺势推给写制度的人，执行端反而没人管。
第四步：出报告、跟踪整改、归档闭环
报告结构固定成四块：审计概况、发现清单、整改建议、跟踪安排。建议要写成可验收的动作，比如「某系统在某时间点前补充告知文本」，而不是「加强管理」。后者谁都没法验收，跟踪表上永远关不掉。
- 出报告终稿概况段写范围和依据，发现段沿用三段式，别在报告里引入新结论，所有结论都应有对应证据编号。
- 开跟踪表每条问题记责任人、承诺完成时间、验证方式、验证结果。验证方式要提前写，比如查配置还是抽样访谈。
- 逐条验证关闭没有验证结果的问题不算关闭。责任人自己说改好了不算，要有你这边复核的记录。
- 归档至少保留审计方案、证据目录与原件、访谈记录、报告终稿、整改验证记录。
常见问题
审计多久做一次比较合适？
外部监管要求的频次以适用规则为准，内部自查通常按年或按重大变化触发（新增业务、换供应商、出过事件）。刚起步的团队与其定一个撑不住的周期，不如先保每年一轮完整审计加一轮轻量复查，把流程跑顺再加密。
没有专职合规岗，小团队怎么做？
把审计拆到能承担的粒度：一人兼审计负责人，业务侧各出一个人做资料对接，范围先只覆盖核心系统。宁可审得窄但每条都闭环，也不要铺开收一堆填不完的表。人力实在不够时先做资产盘点和制度对照，把整改项攒起来再约正式审计。
审计发现的问题，业务不认怎么办？
回到三段式写法：拿事实和依据说话，补充影响面数据（涉及哪些数据、哪些用户场景）。仍不认的，把分歧点写进报告并注明双方意见，由审计组里有决策权的人裁定档位和整改期限，不要让问题在口头扯皮里消失。
