数据映射与分类分级：数据资产盘点方法论、个人敏感信息识别、数据分类分级标准与标签体系
好，咱们进入第二个实战模块。数据映射与分类分级，说白了就是搞清楚「我们到底有哪些数据，它们长什么样，有多敏感」。
我见过太多企业，一上来就急着做隐私合规，结果连自己服务器上存了什么都不知道。你想想看，这就像你要打扫房间，却连房间里有什么东西都不清楚——那肯定乱套。
数据资产盘点方法论
数据资产盘点，是隐私合规的「地基」。地基不稳，后面全白搭。
我个人习惯把盘点分成四个步骤：
- 范围界定——先搞清楚盘点的边界。是整个公司？还是某个业务线？还是某个系统？
- 数据发现——用工具扫描数据库、文件服务器、云存储，找到所有数据资产。
- 字段级梳理——对每个数据表、每个字段进行标注，记录它的业务含义。
- 关系映射——搞清楚数据从哪里来、到哪里去、谁在处理它。
核心要点：盘点不是一次性工作，而是持续的过程。我建议每季度做一次增量盘点，每年做一次全量盘点。
我在项目中遇到过一家金融科技公司，他们以为自己的数据资产只有20个系统。结果一扫描，发现实际有87个系统在跑数据。为什么？因为业务部门自己搭了很多小工具、小数据库，IT部门根本不知道。
实战技巧：盘点时别只盯着「正式系统」。Excel表格、本地CSV文件、甚至邮件附件里的数据，往往才是最大的风险点。
个人敏感信息识别
识别个人敏感信息，是分类分级中最关键的一步。为什么？因为敏感信息的处理要求更严格，处罚也更重。
根据《个人信息保护法》，敏感个人信息包括：
- 生物识别信息（指纹、人脸、虹膜）
- 金融账户信息（银行卡号、交易记录）
- 行踪轨迹（GPS定位、出行记录）
- 健康生理信息（病历、体检报告）
- 不满十四周岁未成年人信息
- 宗教信仰、性取向等特殊信息
嗯，这里要注意。很多企业容易犯一个错误：只识别「明显」的敏感信息，比如身份证号、手机号。但像「用户画像标签」「消费习惯分析」这类衍生数据，其实也可能构成敏感信息。
避坑指南：我曾经帮一家电商公司做合规审计，发现他们把用户的「购买药品记录」当作普通消费数据处理。但药品购买记录涉及健康信息，属于敏感个人信息。这个遗漏差点让他们被罚2000万。
识别敏感信息，我推荐用「正则表达式+机器学习」的组合方式。正则表达式抓取明显的模式（比如身份证号18位），机器学习识别模糊的敏感内容（比如病历描述）。
# 一个简单的敏感信息识别示例（Python伪代码）
import re
def identify_sensitive_data(text):
# 身份证号模式
id_pattern = r'\d{17}[\dXx]'
# 手机号模式
phone_pattern = r'1[3-9]\d{9}'
# 银行卡号模式
bank_pattern = r'\d{16,19}'
if re.search(id_pattern, text):
return 'high_sensitive'
elif re.search(phone_pattern, text):
return 'medium_sensitive'
else:
return 'low_sensitive'
数据分类分级标准与标签体系
分类分级的标准，国内目前没有统一的强制标准。但有几个主流框架可以参考：
| 标准/框架 | 分级方式 | 适用场景 |
|---|---|---|
| GB/T 35273-2020 | 个人一般信息、个人敏感信息 | 个人信息保护 |
| JR/T 0171-2020 | C1-C4四级 | 金融行业 |
| 数据安全法要求 | 核心数据、重要数据、一般数据 | 数据安全 |
我个人习惯用「三级分类+五级分级」的体系。为什么？因为太细了业务部门记不住，太粗了又不够用。
三级分类：
- 个人信息类（姓名、电话、地址等）
- 业务数据类（交易记录、订单信息等）
- 技术数据类（日志、API调用记录等）
五级分级：
- L1 公开数据——对外公开，无风险
- L2 内部数据——仅限内部使用，泄露影响小
- L3 敏感数据——泄露会造成中等影响
- L4 高度敏感数据——泄露会造成严重影响
- L5 核心数据——泄露会造成灾难性影响
标签体系设计原则：标签要「机器可读、人工可理解」。我建议用「分类_分级_业务域」的命名方式，比如「PII_L3_CRM」表示CRM系统中的L3级个人信息。
你想想看，有了这套标签体系，后续的数据访问控制、脱敏处理、跨境传输评估，就都有了明确的依据。比如L4以上的数据，默认不允许导出到生产环境之外。
我记得有一次帮一家物流公司做数据治理，他们之前的数据标签乱七八糟，有的叫「客户信息」，有的叫「收件人资料」，还有的叫「联系人数据」。统一成标准标签后，光数据脱敏的效率就提升了40%。
实战建议：标签体系不要一次性搞太复杂。先跑通「分类+分级」两个维度，等业务部门习惯了，再逐步增加「数据来源」「处理目的」「保留期限」等维度。
最后说一句，数据映射与分类分级，不是IT部门自己的事。一定要拉上业务部门一起做。为什么？因为只有业务部门才知道某个字段到底存的是什么数据、有多重要。我见过太多「IT闭门造车，业务一脸懵逼」的失败案例了。
嗯，这一章的内容就到这。下一章咱们聊聊数据保护影响评估（DPIA）怎么做，那是另一个硬骨头。