观点：数据分类分级中的协同

数据分类分级工作，从最初的概念到现在的多行业落地实践，经历了多轮探索磨合。现在整理下数据分类分级工作中多部门协同的部分，按项目阶段和协同事项重新整理，便于在方案设计、实施、测试、验收和运营交接中直接对照使用。

一、总体协同原则

项目应形成“需求—测试用例—通过条件—责任人—证据”对应表，采购、实施、测试和验收都围绕该表执行。其中多部门职责分工如下：

• 业务部门：划定范围、确认数据含义、必要用途和业务链路中的合法使用场景。
• 数据安全归口部门：维护判定规则、组织分级争议裁决、确认判定样例。
• 科技部门：验证采集、集成、性能和技术控制。
• 实施方：负责实现、整改并提供证据。
• 合规、风险、审计部门：按各自职责开展审查监督，审计保持独立性。

二、方案设计阶段

1. 资产范围交叉确认 资产范围不能只依赖工具扫描结果，应由行内台账、元数据平台、业务访谈和技术发现结果交叉确认。业务部门参与业务访谈，确认资产的实际业务含义和使用场景。
2. 判定样例库建设 建立经业务和数据安全归口部门确认的判定样例库。样例至少包含数据含义、使用场景、类别、级别、判定依据及容易混淆的反例。业务部门负责确认数据含义和使用场景，数据安全归口部门负责审核判定依据。
3. 验收样本建设 由业务人员确认数据含义，安全人员审核判定依据，再形成固定版本的验收样本。样本应覆盖不同业务条线、系统类型、数据格式和风险层次。
4. 验收阈值提前约定

各项阈值应结合风险、样本和业务承受能力提前约定，不宜把统一“95%”套到所有对象上。这里需要业务部门参与判断业务承受能力。

三、实施与测试阶段

1. 业务链路贯穿测试 选取代表性银行业务链路，例如“客户信息采集—数据仓库加工—业务查询—报表导出—接口提供”。每条链路同时验证合法使用和违规使用： 有权限用户能否完成必要业务，展示结果是否符合脱敏要求；无权用户能否通过接口、批量导出或其他访问通道取得数据；权限撤销后缓存和下游系统能否及时更新；标签变更后执行系统是否真正采用对应策略；日志能否关联操作者、数据对象、审批记录和策略版本。 业务部门需确认“必要业务”的边界和合法使用场景；科技部门验证技术控制；实施方提供实现和证据。
2. 生产影响测试 在约定负载下测试扫描开销、访问延迟、批处理影响及恢复能力。业务部门参与判断业务承受能力，科技部门负责技术验证。
3. 争议样本处理

对存在争议的样本，先记录争议理由，由指定责任部门给出结论，再形成新的基线版本，并对受影响对象统一回归测试。不能每次测试不通过就临时修改判定标准。业务部门确认数据含义和必要用途；数据安全归口部门维护判定规则并组织分级争议裁决；科技部门验证技术控制；实施方负责整改并提供证据。

四、验收与争议阶段

1. 明确裁决分工
   • 业务部门：确认数据含义和必要用途。
   • 数据安全归口部门：维护判定规则、组织分级争议裁决。
   • 科技部门：验证采集、集成、性能和技术控制。
   • 实施方：负责实现、整改并提供证据。
   • 合规、风险和审计：按职责审查监督，审计保持独立性。
2. 验收结论分类 验收结论区分“通过”“附条件通过”和“不通过”。附条件通过必须有明确缺陷、补偿措施、责任人、完成期限和复验条件。涉及关键保护失效的缺陷，不应靠一份风险接受记录直接消除。这里需要业务部门、数据安全归口部门、科技部门和实施方共同确认缺陷性质和补偿措施。
3. 验收文件可追溯

验收文件最终应能逐项回答：这个对象为什么这样分级，谁确认了结果，执行了什么保护，以及用什么证据证明保护有效。“谁确认了结果”需要明确业务部门、数据安全归口部门、科技部门和实施方各自的责任人。

五、运营交接阶段

1. 交接内容 交付物除软件和报告外，还应包括规则及版本、资产和标签目录、人工复核队列、异常处置流程、变更审批流程、运行手册和培训记录。这些内容涉及业务部门、数据安全归口部门、科技部门和实施方的共同交接。
2. 试运行期独立操作

在约定试运行期内，让行内团队独立完成：一次新增资产识别；一次判定争议处理；一次策略调整；一次故障恢复。通过这些操作判断项目是否具备持续运行条件。其中判定争议处理需要业务部门参与，策略调整需要数据安全归口部门参与，故障恢复需要科技部门参与。

六、按部门归集的协同事项速查表

总结

业务部门的核心作用是确认数据含义、必要用途和业务承受能力；数据安全归口部门负责规则维护和争议裁决；科技部门负责技术验证；实施方负责实现、整改和举证；合规、风险、审计负责监督审查。多部门协同应贯穿资产范围确认、样例库建设、验收样本、业务链路测试、争议裁决、验收结论和运营交接全过程。