先对齐概念：重要数据不等于敏感个人信息
2024 年 10 月 1 日实施的 GB/T 43697-2024《数据安全技术 数据分类分级规则》给出了通用规则，把数据级别划分为核心数据、重要数据、一般数据三个等级。同时，《网络数据安全管理条例》第五条也明确国家对网络数据实行分类分级保护。
但在项目现场，最容易混淆的是两套完全不同的视角：
| 对比项 | 重要数据 | 敏感个人信息 |
|---|---|---|
| 判断视角 | 国家安全、经济运行、社会稳定、公共健康和安全 | 个人权益、人格尊严、人身财产安全 |
| 依据 | 《数据安全法》、GB/T 43697-2024、行业重要数据目录 | 《个保法》第二十八条 |
| 典型后果 | 需识别申报，年度风险评估并报送主管部门 | 需单独同意、事前 PIA、更严格的最小必要 |
| 常见误解 | "客户名单肯定是重要数据"——多数情况下并不构成 | "数据量大就是重要数据"——两回事 |
把这两套视角混在一张表里，是很多项目第一次失败的原因。
三大卡点
卡点一：业务理解——安全团队不懂业务，业务团队不认安全
典型场景是安全团队拿着模板找业务部门填表，业务部门填了三行就交差，因为"不知道你们要干什么"。解法是先做数据资产盘点而不是先做分类分级表：以业务系统为主线，顺着"系统 → 模块 → 表 / 文件 → 字段"往下走，每张核心表都由业务负责人确认用途和数据主体。定级结论必须有业务签字，否则后续管控措施落不下去。
卡点二：组织协同——谁来定级、谁承担后果
分类分级天然是一个跨部门项目。没有明确的数据 Owner，就会出现"安全定级、业务不认、运维不知道要做什么"。解法是成立数据安全工作小组，明确每个数据域的 Owner 与定级责任人，并把定级结果写入系统变更流程——新增字段、新增对外接口时自动触发定级评审。
卡点三：工具选型——先买平台，规则却是空的
这是最常见的投入顺序错误。分类分级平台的价值在于"把已经有共识的规则自动化"，而不是"替企业想出规则"。规则还没跑通就上平台，结果往往是平台里塞满人工标注，项目越做越重。解法是先选一个小范围（建议 1 个业务系统、20 张左右核心表）手工跑通，沉淀出分类维度、分级判定条件、命中规则后，再上工具做规模化。
四步落地路径
- 第一步 识别：形成数据资产清单，覆盖结构化数据与非结构化数据（文档、邮件、图纸、音视频），标注数据来源、存储位置、流转路径、责任部门。
- 第二步 分类：按业务属性分类（如客户数据、财务数据、研发数据、人事数据），并与行业分类规范对齐。
- 第三步 分级：先定"是否重要数据 / 核心数据"，再定个人信息敏感程度，最后落到一般数据的内部敏感级别。分级要给出可复现的判定条件，而不是凭经验打标签。
- 第四步 管控映射：把级别与具体管控措施挂上钩——加密、脱敏、访问审批、水印、审计、导出限制、留存期限。分级没有对应措施，等于白做。
四个常见误区
- 把"敏感个人信息"和"重要数据"混为一谈。两套视角要分开判定，最后在管控层合并。
- 定级只做一次。业务在变，数据在新增，定级必须跟着变更流程走，否则一年后清单就失真了。
- 只做结构化数据。实际泄露事件中，非结构化文件（图纸、合同、报价单）占比往往更高，却最容易被遗漏。
- 分完级就锁进抽屉。没有差异化管控的分级结果，既通不过检查，也挡不住风险。
交付物清单
| 阶段 | 应交付的成果 |
|---|---|
| 识别 | 数据资产清单、数据流转图、责任部门与 Owner 对照表 |
| 分类 | 数据分类目录、业务系统分类映射表 |
| 分级 | 分级判定规则、重要数据 / 核心数据识别结论、个人信息敏感度标注 |
| 管控 | 分级管控措施矩阵、平台建设需求说明、变更流程嵌入方案 |
结语
分类分级不是一次性交付物，而是一项需要持续维护的基础工作。判断项目是否成功只有一个标准：一年之后，新上线的业务系统能不能自觉地按规则完成定级。
想先在一个业务域把分类分级跑通？
我们可以用一个小范围试点做出可复制的规则库，再决定平台化建设的节奏。