2. 数据分类方法论：按业务维度分类、按数据属性分类、按敏感程度分类、分类标准制定原则

好，咱们直接进入正题。数据分类这件事，说白了就是给数据「贴标签」。但怎么贴、贴什么，这里头门道不少。我做了这么多年数据治理，见过太多团队一上来就搞「敏感数据分级」，结果发现业务部门根本不认——为什么？因为分类维度没选对。

我个人习惯，先把分类维度分成三大类。你想想看，就像整理衣柜，你可以按季节分、按颜色分、按材质分。数据也一样，关键看你想解决什么问题。

这是最贴近实际业务的分类方式。说白了，就是数据在业务场景里「长什么样」。

常见业务分类维度：

我的经验：我在一家电商公司做项目时，业务部门坚持要把「用户浏览记录」归到「营销数据」里。但后来发现，这个数据其实同时服务于推荐算法、风控模型和客服分析。所以啊，业务分类最好允许「一数据多标签」，别搞一刀切。

业务分类的优缺点：

这个维度更偏技术视角。嗯，这里要注意，数据属性分类不是用来给业务看的，而是给数据工程师、架构师用的。

常见属性分类维度：

我曾经遇到一个坑：团队把所有非结构化数据（比如图片、视频）都归为一类，结果做数据脱敏时发现，图片里的身份证信息根本没法用常规工具处理。所以啊，属性分类要结合后续的数据处理能力来设计。

避坑指南：我曾经见过一个团队，把「数据属性分类」和「业务分类」混在一起，搞出一个四不像的分类体系。结果业务看不懂，技术也用不上。记住，这两个维度是正交的，可以共存，但别混为一谈。

这才是数据安全的核心。敏感程度分类，说白了就是「哪些数据丢了会出大事」。

常见的敏感等级划分：

我个人习惯，在敏感程度分类上，一定要留一个「灰色地带」。为什么？因为有些数据在不同场景下敏感度不一样。比如用户的「收货地址」，在物流场景下是必要信息，但在营销场景下就是敏感数据。

    关键原则：敏感程度分类不是一成不变的。数据在「使用中」「传输中」「存储中」的敏感度可能不同。我建议给每个数据项打三个标签：静态敏感度、动态敏感度、使用敏感度。

好，前面讲了三种分类维度，但怎么落地？我总结了几条原则，都是踩过坑之后才明白的。

原则一：业务驱动，技术支撑

别让数据团队关起门来搞分类。我见过最离谱的项目，数据团队花了三个月搞出一套分类标准，结果业务部门说「这跟我们没关系」。正确的做法是：让业务负责人参与分类维度的定义，技术团队负责落地实现。

原则二：可扩展，别做死

你想想看，业务在变，数据在变，法规也在变。分类标准如果定得太死，过半年就得推倒重来。我建议用「分类标签」的方式，而不是「分类树」的方式。标签可以叠加，可以新增，灵活得多。

原则三：可度量，能验证

「这个数据比较敏感」——这种说法不行。要量化。比如：

有了量化标准，自动化工具才能帮你做分类。

原则四：最小化原则

分类维度不是越多越好。我见过一个团队搞了20多个分类维度，结果没人记得住。一般来说，3-5个核心维度就够了。其他的可以作为辅助标签存在。

我的建议：刚开始做分类时，先选一个业务域试点。比如先做「客户数据」的分类，跑通流程后再推广。别一上来就想覆盖全公司，那样大概率会失败。

原则五：与合规要求对齐

这个不用多说。GDPR、个人信息保护法、数据安全法，这些法规对数据分类有明确要求。我建议在制定分类标准时，直接引用法规中的定义，比如「个人敏感信息」的定义就按《个人信息保护法》来。

好了，分类方法论就讲到这里。下一章我们聊聊具体的分类实施步骤，包括怎么建分类矩阵、怎么落地到系统里。到时候我会拿一个真实的案例来拆解，保证你能直接用上。