2、合规需求分析：如何梳理合规需求、合规需求分类（法规、行业标准、企业内部）、需求优先级评估

好，咱们进入正题。上一章聊了选型前的准备工作，这一章咱们来啃一块硬骨头——合规需求分析。

说实话，我见过太多团队一上来就急着看工具、比功能，结果工具买回来发现根本覆盖不了核心需求。为什么？因为需求没理清楚。你想想看，连自己要管什么都不知道，怎么选工具？

我个人习惯，做任何合规自动化项目之前，先花至少一周时间把需求彻底梳理一遍。这一步省不了，也急不得。

2.1 如何系统性地梳理合规需求

梳理需求，说白了就是回答三个问题：

• 我们要遵守哪些规则？（法规、标准、内部制度）
• 这些规则要求我们做什么？（具体动作、记录、报告）
• 哪些环节可以自动化？（人工操作多、重复性高、出错率高的地方）

我在项目中遇到过一种情况：客户说“我们要做GDPR合规”，结果一梳理，发现他们连数据资产清单都没有。这就好比你要盖房子，但连地基在哪都不知道。所以，梳理需求的第一步，永远是盘点现状。

具体怎么做？我建议分三步走：

1. 访谈关键角色：法务、合规、IT、业务负责人，每个人视角不同。法务关注条款，IT关注技术实现，业务关注流程影响。
2. 收集现有文档：已有的合规清单、审计报告、整改记录、流程文件。别小看这些，里面藏着大量真实需求。
3. 绘制合规地图：把法规要求映射到具体业务流程上。比如“数据保留期限”这条要求，对应到CRM系统的客户数据删除流程。

2.2 合规需求分类：法规、行业标准、企业内部

需求梳理出来后，别急着一股脑全塞给工具。先分类。我一般分成三大类：

2.2.1 法规类需求

这是硬性要求，不满足就是违法。比如：

• 《个人信息保护法》中的“告知-同意”机制
• GDPR中的“数据可携带权”
• 《网络安全法》中的“等级保护”要求

这类需求优先级最高，没有商量余地。工具必须支持，否则直接淘汰。

2.2.2 行业标准类需求

虽然不是法律，但行业里大家都这么做。你不做，客户不信任你，审计过不了。比如：

• ISO 27001的信息安全管理体系要求
• PCI DSS的支付卡数据安全标准
• SOC 2的信任服务准则

这类需求，我建议尽量满足。尤其是你要服务金融、医疗、政务这些行业，行业标准就是准入门槛。

2.2.3 企业内部类需求

这是最容易被忽略的。比如：

• 公司内部的“数据分级分类管理办法”
• IT部门的“日志保留90天”规定
• 法务部的“合同审批必须留痕”要求

嗯，这里要注意。内部需求虽然优先级不如法规高，但往往是工具落地时最卡脖子的地方。我曾经遇到一个项目，工具功能很强大，但就是没法适配客户内部的“双人审批”流程，最后不得不二次开发，工期拖了两个月。

2.3 需求优先级评估：怎么排先后？

需求列了一大堆，但资源有限，不可能全做。怎么排优先级？我有一套自己的评估方法，分享给你。

我习惯用“影响程度 × 紧急程度”矩阵来打分：

维度	评分标准	分值
影响程度	违法风险 / 客户流失 / 审计不通过	1-5分
紧急程度	监管限期 / 客户要求 / 内部deadline	1-5分
实现难度	工具原生支持 / 需配置 / 需定制开发	1-3分（越低越好）

最终优先级 = (影响程度 × 紧急程度) / 实现难度。得分高的先做。

另外，我建议把需求分成三个批次：

• 第一批（MVP）：覆盖核心法规需求，能跑通基本流程。比如GDPR的数据主体请求处理、数据泄露通知。
• 第二批（增强）：加入行业标准需求，提升合规成熟度。比如ISO 27001的持续监控、审计日志。
• 第三批（优化）：处理内部定制需求，提升用户体验。比如自定义审批流、报表模板。

这样做的好处是，工具能快速上线，先解决最痛的问题。后面再慢慢迭代，不会一上来就被复杂需求压垮。

2.4 一个真实案例

讲个我亲身经历的项目吧。一家金融科技公司要选合规自动化工具，需求清单列了80多条。我帮他们梳理后，发现真正核心的只有15条：

• 法规类：反洗钱交易监控、客户身份识别（KYC）、数据跨境传输审批
• 行业标准类：PCI DSS的持卡人数据加密、ISO 27001的访问控制
• 内部类：内部审计报告自动生成、合规培训记录管理

剩下的65条，要么是“锦上添花”，要么是“以后再说”。最终他们选了一款工具，第一批上线只做了这15条需求，3个月就通过了监管检查。你想想看，如果当时贪多求全，可能现在还在需求评审会上吵架呢。

所以，我的建议是：需求分析不是列清单，而是做决策。知道什么该做，什么不该做，比知道怎么做更重要。