合规管理 风险识别清单

很多人第一次做合规风险识别，卡在两个地方：一是不知道从哪里下手，二是填出来的表全是「可能存在合规风险」这种废话，评审时没人认。这篇给一套可照着填的维度拆解、字段口径和一份示例填法，还顺带说清什么规模的团队不必上全套。

很多人第一次做合规风险识别，卡在两个地方：一是不知道从哪几个方向下手，二是填出来的表全是「可能存在合规风险」这种没法验证的话，评审的时候没人认，最后变成一份谁也不看的文档。这篇把清单拆成可以照着填的维度、字段和示例，顺带说清什么规模的团队不必上全套。

先说一个前提：清单不是用来证明你合规的，而是用来让问题在发生前被一个人认领。所以判断清单好不好，标准只有一条——随便挑一行，能不能指出谁在什么时候做什么动作。做不到，就是维度切得不对或者字段设得太虚。

先定维度：一张清单要覆盖哪几层

最常见的错误是按部门列，市场部、技术部、客服部各写几条。这种列法会漏掉跨部门流程，比如用户数据从客服转到技术再转给外部接口，三个部门都觉得自己只管一段。更稳的做法是按「业务环节 × 风险类型」交叉铺开，让每个交叉点对应一个具体动作。

• 按业务环节横向铺开，再按风险类型纵向切，不要只按部门列；
• 每一层拆 2-4 个动作点就够，拆太细没人填得完；
• 每个动作点必须能被一个人独立认领，认领不了说明拆得还不够细；
• 只有 1-2 条业务线的小团队，可以直接砍掉「主体与资质」里的大部分条目，别硬凑层数。

字段怎么设：别只写「有没有风险」

字段决定这张表能不能用。只写「是否有风险」加一个勾选框，等于什么都没写，因为没人知道这个判断是怎么来的、什么时候会变。建议固定七个字段，缺一个都会在复查时扯皮。

环节

这个动作发生在业务流程的哪一步，用动词描述，别写部门名

触发条件

什么可观察的事件出现时这条风险才会被激活

可能后果

被投诉、被处罚、被索赔三类分开写，应对动作不一样

现有控制

实际在做的动作，写制度名不算，制度没执行等于没有控制

剩余风险

做完现有控制之后还剩多少，用高 / 中 / 低三档即可

责任人

写到岗位，不写「全员」

复核时间

季度或半年粒度，写死具体日期反而没人跟

其中「触发条件」和「现有控制」是最容易被写虚的两个。触发条件要写成可观察事件，比如「对接了新的第三方接口」，而不是「可能存在违规」。现有控制要写正在执行的动作，比如「上线前逐项核对输入字段」，而不是「遵守相关法规」。

填写示范：一条完整条目长什么样

拿一个通用场景举例：一家 5 人小团队把用户提问转给外部模型接口处理。这条风险如果写成「数据泄露风险，高」，评审时基本会被打回。下面按字段展开成一条能认领的条目。

1. 先写环节写成「用户提问转外部接口」，描述动作而不是部门，别人一看就知道流程走到哪。
2. 再写触发条件写成「新增外部接口或更换服务商时」，这是一个可观察事件，能对应到具体的上线动作。
3. 写现有控制写成「上线前逐项核对输入字段，屏蔽身份类字段，并保留一份调用记录」，全部是实际会做的动作。
4. 最后落责任人和复核时间责任人写到岗位，比如技术负责人；复核时间给季度粒度，季度末过一遍变化条目。

这条填完之后，下次有人要接新接口，第一条就知道该去核对输入字段，而不是等到出事再回头翻文档。清单的价值就在这里：把判断变成动作。

复查与更新：什么时候重填这张清单

清单最怕的是填完就锁进文件夹。判断要不要动这张表，看四类触发点：业务范围变了、合作方变了、监管口径变了、以及已经发生过一次实际投诉或事故。这四类出现哪一类就动，没出现就别全表重填，全表重填只会让责任人敷衍签字。

• 只改动变化条目，并在备注里写清为什么改，方便下次追溯；
• 把清单和日常动作挂钩，比如新接入第三方前先过一遍对应条目；
• 每次复查留一份核对记录，清单本身不算证据，能拿出来的是记录和日志；
• 已经踩过坑的条目要升级复核频率，从季度改成月度。

关于留存方式、哪些记录在纠纷里更有用，可以对照站内的指南页面看具体做法。另外，如果你选的外部服务商本身也需要做一轮可信度判断，可以先到 中转站导航（/sites） 看各家的情况，再决定要不要写进现有控制里。