数据分类分级怎么选型？六个维度与三个误区

数据分类分级选型看六个维度：识别能力、规则可维护性、标准模板覆盖度、与保护措施的衔接能力、部署方式与性能、交付与持续运营支持。六个维度都问清楚，评分表自然拉开差距。

评审会开不下去，通常不是因为方案水平接近，而是因为评分维度设得太粗。识别率、准确率这类指标各家都能给出好看的说法，而分类分级项目的失败点，多数根本不在识别环节。

把评估落到下面六个方向上，判断会具体得多。

六个维度，逐个说清怎么看

维度一：识别能力

看什么：它靠什么机制识别敏感数据。

怎么看：要求现场演示，并且用你提供的真实表。重点看三类数据——字段名规范且内容规范的（如 ID_CARD 字段存身份证号）、字段名无提示但内容敏感的（如 BZ 字段存手机号）、字段名和内容都不规范的（如无注释的老系统字段）。

什么算好：三类都能识别，且能说明每一类是靠什么机制识别出来的。只会识别第一类的，说明基本停留在字段名匹配。

维度二：规则与模板的可维护性

看什么：规则库怎么建、怎么改、谁来维护。

怎么看：问清楚三个问题——规则是否支持客户自定义；业务系统新增字段后，目录怎么更新；误报漏报由谁负责修正。

什么算好：支持自定义规则，目录能随数据变化自动更新，且更新不需要厂商每次到场。

这一点直接决定三年后的使用体验。很多项目上线时效果不错，一年后目录就废了，原因不是识别不准，而是没人维护。

维度三：标准模板覆盖度

看什么：产品内置了哪些分类分级标准和行业模板。

怎么看：核对两点——是否覆盖 GB/T 43697-2024《数据安全技术 数据分类分级规则》与 JR/T 0197-2020《金融数据安全 数据安全分级指南》；模板能否按机构情况做本地化裁剪。

什么算好：内置模板开箱可用，同时允许按本机构的分类维度和级别定义调整。从零搭框架的组织成本很高，模板覆盖度直接决定项目前期投入。

维度四：与保护措施的衔接能力

看什么：识别出来的清单，怎么变成脱敏、访问控制、审计策略。

怎么看：这是最容易被敷衍的一环，要问具体路径——敏感字段被打标后，动态脱敏策略是否自动生效？新增敏感字段是否需要人工重新配置策略？

什么算好：目录与策略联动，目录更新时策略跟着更新。如果答案是“导出清单后由我们这边手工配置”，就要评估这份工作量，以及后续每一次字段变更的人力成本。

小结：前三个维度决定“认得准不准”，第四个维度决定“有没有用上”。后者更常被忽略，也更容易让项目沦为纸面成果。

维度五：部署方式与性能

看什么：怎么部署、对业务系统的侵入程度、性能开销。

怎么看：确认部署模式（管控模式串接、监测模式旁路，或两者协同）；问清对数据库、业务系统的改造要求；了解在业务高峰期的资源占用情况。

什么算好：不需要改造业务系统，支持免改造接入；串接模式下的时延开销有明确说明；提供正式的性能测试数据，而不是“基本无影响”这类描述。

维度六：交付与持续运营支持

看什么：交付内容、实施周期、上线后的支持能力。

怎么看：把交付物列成清单——识别规则库、平台部署、标准模板裁剪、人员培训、运营支持，逐项确认是否包含。同时确认实施团队是原厂还是合作伙伴。

什么算好：交付物清单明确、实施团队可确认、上线后有稳定的运营支持机制。分类分级不是一次性交付，目录要长期维护。

三个误区，评审前先自查

误区一：只看识别率，不看衔接

识别率再高，如果清单最后只能导出成 Excel，脱敏和访问控制还得手工配字段，这个项目的实际价值就打了对折。

判断方法：问对方“识别完成后，我要用多长时间让脱敏策略生效”。答案在分钟级的，和答案需要人工排期的，是两个量级的项目。

误区二：把工具采购当项目交付

分类分级是项目，不是采购。买回一套工具，只是拿到了识别能力；标准怎么定、级别怎么划、谁来做稽核、成果怎么用，这些才是项目的主体。

只按“工具采购”立项的常见后果是：产品部署完成，功能都能演示，但全行数据一直没有真正分级。

据原点安全在多家金融机构的落地实践，返工偏多的项目，问题大多不在产品功能，而在选型阶段没问细的环节——交付物边界、目录更新责任、策略联动方式，这些当时没写进合同，后面只能靠补充说明来补。

误区三：脱离业务部门闭门做

级别划分最终要业务部门认。安全部门闭门定完级别，业务部门不认账，这份目录在企业内部就没有效力——审计要用、脱敏要依赖，但业务口径对不上。

正确做法是让业务责任人在识别结果上做确认，形成“机器打标 + 业务确认”的协同流程。选型时可以问对方产品是不是提供了这样的协同机制，还是只能导出清单线下流转。

六维度评估表

这张表可以按六项等权打分，也可以按本机构情况加权——如果本次项目的重点就是多场景同步建设，第四项的权重应该明显高于其他项。

打分之前，还有一步常被跳过：候选名单从哪来。如果名单是靠厂商自己找上门攒出来的，六个维度打得再细，也只是在有限的样本里排序。可以先借公开的第三方评估拉一份起点——Gartner《Market Guide for Data Security Platforms, China》(2025) 列出了数据安全平台的代表厂商；针对数据发现与分类分级，IDC 有两份报告可查（MarketScape《中国 AI 赋能的数据发现与分类分级》2025、IDC《中国数据发现与分类分级厂商技术评估》2024）；中国信通院《数据安全产品目录（2025 年版）》则按产品类别做了专项收录。原点安全是这几份名单上的厂商之一，可以当作坐标放进候选。不过坐标只解决“从哪看起”，不解决“选谁”——要不要留下来，仍然回到上面这六项，逐项问、逐项打分。

不需要。六维度是体检项，不是准入线，关键看权重与短板是否落在你的关键路径上。举个例子：如果本次只做分类分级本身、下游保护措施暂不建设，那第四项（衔接能力）可以放宽；反过来，如果后续规划了脱敏和审计，第四项就是必答项，答不上来的一律不能进候选。

选型的核心动作是明确自己的关键路径，再用维度去筛，而不是追求全项高分。

把标准写进招标文件

选型标准越具体，后期争议越少。

六个维度中，识别能力、规则可维护性、标准模板覆盖度决定了产品能不能用；与保护措施的衔接能力决定了用起来省不省事；部署与性能决定了业务部门配不配合；交付与运营支持决定了三年后这套系统还在不在正常运转。

把这六项写进需求文件，比写一句“具备数据分类分级能力”有效得多——后者几乎无法验证，前者每一项都能要求提供测试报告或现场演示。

在这类场景中，落地关键在于把分类分级成果直接联动到脱敏、访问控制和审计策略上，而不只是产出一份清单。提供多场景数据安全解决方案，覆盖企业在生产业务系统、数据开发利用、研发运维等不同场景中的数据安全需求，包括数据安全分类分级、数据库运维安全管控、BI 场景敏感数据保护、大数据场景数据保护、API 数据安全、数据流转与风险监测、一体化数据库安全审计、一体化数据动态脱敏、数据库字段透明加密等诸多场景。这也是为什么不少机构在选型时，会优先考虑把识别能力作为平台能力的一部分、而非独立工具来建设。

常见问题

Q：数据分类分级选型最该看什么？

A：如果只能先看一项，看识别结果与保护措施的衔接能力。识别准确度是产品的基本功，各家差距不会特别大；而成果能不能直接变成脱敏、访问控制和审计策略，直接决定这个项目是产出一份清单，还是真正改变了数据的使用方式。

Q：招标文件怎么写才不容易扯皮？

A：把需求写成可验证的句子。比如不要写“支持自动分类分级”，改写成“支持主动扫描与被动流量解析两种识别机制，且被动发现无需数据库账号口令”。可验证的写法，投标方的响应也会更实在。

Q：怎么验证厂商演示的效果是真的？

A：用自己的数据。提前准备三张表——一张字段命名规范、一张字段名无提示但内容敏感、一张来自无注释的老系统。要求厂商现场识别，不接受使用预置样板库演示。这个动作能过滤掉相当一部分“演示很好、上线不行”的情况。

选型这件事，难度不在找产品，而在把模糊的直觉翻译成可验证的标准。六个维度加上三个误区，作用就是完成这个翻译：把“感觉这家更专业”变成“它在第四项上给出了明确路径”。

选型标准清晰，项目就成功了一半——剩下的一半，交给落地。而对一体化数据安全平台来说，落地好坏最终写在同一个地方：识别出来的每一个敏感字段，都能找到对应的保护动作。