
本文拆解 DCMM 2.0 安全域的三项核心能力——数据合规管理、数据安全防护、数据安全审计,梳理其与《数据安全法》《个人信息保护法》和等保 2.0 的联动逻辑,并基于五级成熟度模型分析企业对标准备的可行路径。
国内一家能源类集团企业在为 DCMM 贯标评估做准备时,数据质量团队整理了一份涵盖数十个系统、数千张表的质检报告,数据标准团队梳理了主数据和参考数据规范——两个域的评估材料加起来接近三百页。但当评估组进入数据安全域审核时,对方只问了三个问题就放下了材料:"你们的分类分级标准是按业务流程划分的还是按系统划分的?上一次全量安全审计是什么时候?审计结果是否有闭环的整改记录?"
这三个问题暴露出一个结构性差距:数据质量和数据标准可以通过项目周期突击补齐,但数据安全域的评估依赖的是日常运转中的制度执行痕迹和持续的合规记录——临时准备的痕迹在专业评估师面前几乎无法掩盖。
DCMM 2.0(GB/T 36073-2025)于 2025 年 12 月 31 日发布、2026 年 7 月 1 日起正式实施,在九个能力域中将原数据安全域的要求显著增强。这一调整不是孤立的标准修订事件,而是《数据安全法》施行后数据合规要求从"建议性"走向"强制性"的制度映射。DCMM 1.0 时代,安全域经常被视为"有制度、有等保备案证明即可过关"的辅助项;进入 2.0 时代,安全域已成为决定评估总分的关键能力域之一。
DCMM 2.0 标准第 12 章对数据安全域进行了重新定义:1.0 版本中的"数据安全策略"和"数据安全管理"两项被重构为数据合规管理和数据安全防护,数据安全审计保留并强化。三项能力形成了从制度建立到执行落地再到可追溯验证的完整闭环。
数据合规管理考察的是企业是否建立了可执行、可检查的数据安全制度体系,以及该体系是否与业务实际运转相衔接。
DCMM 2.0 对这项能力的要求明显高于 1.0 时代的"数据安全策略"。旧版侧重于安全方针的有无——企业有一份安全策略文件、明确了一名安全负责人,基本就能拿到对应分数。2.0 版本则进一步要求:策略不仅要有,还必须落实到分类分级制度、访问控制规范、数据脱敏规则、安全事件应急预案等可操作层面,并且这些制度要有定期评审和更新记录。
分类分级是合规管理的制度基础。《数据安全法》第二十一条明确要求国家建立数据分类分级保护制度,这一法律要求直接传导到 DCMM 2.0 的安全域评估中。在实际评估中较多出现的情况是,企业有分类分级文件,但分级标准停留在"公开/内部/机密"三个通用标签,未与具体的数据资产目录关联——哪张表是"机密"、哪个字段属于"内部",在评估时无法给出清晰映射。评估师关注的重点不是分类分级的"有无",而是分类分级标准的可操作性及其在日常管理中的执行证据。
常见失分场景还包括:安全制度仅由 IT 部门制定,未经业务部门和法务部门会签;制度发布后长期未更新,与当前系统架构和业务流程脱节;安全责任人变更后无交接记录。这些看似"流程性问题"的缺口,在 DCMM 2.0 的评估中都会被计入证据缺失项。
如果数据合规管理解决的是"制度是否到位",数据安全防护考察的则是"这些制度在日常数据流转中是否真正运行"。
DCMM 2.0 对数据安全防护的要求覆盖了数据生命周期的多个环节:访问控制(是否实现了按角色、按数据级别的精细化权限管控)、数据脱敏(是否区分了动态脱敏和静态脱敏场景)、加密保护(传输加密和存储加密是否覆盖了全链路)、以及数据流转的安全管控(跨系统、跨组织的数据共享是否经过安全审批和脱敏处理)。
在多组织场景下(如集团-子公司架构),安全防护还面临一个额外挑战:如何在总部统一安全管控和下属单位数据自治之间取得平衡。DCMM 2.0 对此的考察要点包括:是否建立了分层分级的组织安全管控架构、跨组织数据访问是否有独立的审批流程、不同组织之间的数据隔离是否在技术层面落地。
从评估实践来看,安全防护域的主要差距往往不出在工具层面——众多企业已有防火墙、堡垒机、数据库审计等基础安全设施——而是出在这些安全能力与数据治理体系的耦合程度上。例如,一个常见的场景是:数据库层面已经配置了访问控制,但数据中台的数据服务接口对同一张表的数据查询并未继承数据库的权限策略。这种"安全工具在、安全策略未穿透"的情况,是 DCMM 2.0 评估中高频出现的扣分项。
数据安全防护可以抽象为三层防线:第一层是基础设施层(网络边界、主机安全、数据库基线配置),核心任务是建立基础防护面;第二层是数据平台层(访问控制、脱敏加密、流转审批),核心任务是将安全策略嵌入数据流转管道;第三层是应用与审计层(操作审计、行为分析、合规报告),核心任务是让每一次数据访问都可追溯。三层防线的关键是垂直穿透——基础设施层的权限配置、平台层的脱敏策略、审计层的日志粒度需要在同一套分类分级标准下统一调度,而非各自为政。
安全审计是安全域三项能力中最容易被低估、却在评估中失分最集中的一项。DCMM 2.0 对安全审计的要求显著强化:日志不仅要"有",还必须"可检索、可追溯、可举证"。
这与《数据安全法》第二十九条的要求直接对应——数据处理活动应当保持可追溯的记录。在企业评估中,安全审计的典型失分形态有三种:其一,日志存在但不可检索——安全审计系统记录了数据访问日志,但审计人员需要从海量日志中手工筛选,无法按"某部门某时间段访问某类数据"进行快速检索;其二,审计记录与业务操作脱节——日志记录的是数据库层面的 SQL 操作,无法关联到具体的业务场景和操作人员身份,评估师无法判断某次批量数据导出的业务合理性;其三,审计发现无闭环——安全审计报告指出了若干不合规操作,但没有对应的整改记录和复核确认,审计沦为"例行报告"而非"管理工具"。
华东地区一家能源类集团的案例颇具代表性。该集团在采购数据治理项目中,将采购监督机制从传统的"事后审计"升级为"过程预警"——数据平台自动识别异常采购模式(如短时间高频询价、单一供应商采购集中度异常),在流程中嵌入预警节点而非等到季度审计时才回溯问题。这种从"事后发现"到"过程预警"的转变,恰好契合了 DCMM 2.0 安全审计能力所要求的"可举证"和"可追溯"——不是等出了问题再查日志,而是让日志在日常运转中就发挥预警作用。
DCMM 2.0 安全域要求显著增强,其驱动逻辑并非来自标准制定者的主观偏好,而是三道法规叠加形成的制度合力。
2021 年 9 月 1 日施行的《中华人民共和国数据安全法》是中国数据安全领域的首部基础性法律。其核心制度安排——数据分类分级保护制度、数据安全审查制度、重要数据目录管理——直接催生了对数据安全能力可评估、可度量的制度需求。DCMM 2.0 安全域加强,本质上是对数据安全法"分类分级→安全保护→安全审查"逻辑的评估框架映射。
在实践中较为典型的场景是:企业因数据安全法合规要求建立了分类分级制度,但该制度的产出(分类分级目录、安全保护措施清单)仅用于向上级主管单位报送,未与日常的数据管理流程打通。DCMM 2.0 的合规管理能力恰好将这两端串联起来,要求分类分级不仅是"政策提交物",更是数据管理活动的基础设施。
与数据安全法同年通过、稍晚施行的《中华人民共和国个人信息保护法》(2021 年 11 月 1 日施行),从个人权益保护维度提出了更精细的要求:告知-同意机制、最小必要原则、删除权与可携带权。这些要求在 DCMM 2.0 安全域中体现为对数据脱敏和访问控制的更高标准——例如,数据脱敏不再只是"对外共享时脱敏",而是需要区分不同共享场景(内部分析、外部合作、监管报送)采用不同的脱敏策略。
GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》(等保 2.0)从系统层面规定了网络安全防护的技术要求,DSMM(数据安全能力成熟度模型)则聚焦于组织的数据安全过程能力。DCMM 2.0 安全域与这两者形成"系统安全→过程安全→管理成熟度"的横纵互补关系。
这种互补关系意味着:企业在准备 DCMM 评估时,等保备案证明和 DSMM 认证结果可以作为辅助材料,但不能替代 DCMM 安全域要求的制度执行记录和审计证据。评估师的关注点不是"你通过了等保几级",而是"你的数据管理活动中的安全实践是怎样的"——两者的评估尺度和证据维度存在本质差异。
法规/标准 | 核心维度 | 与DCMM 2.0安全域的关系 |
|---|---|---|
《数据安全法》 | 数据层面的合规 | 分类分级制度→合规管理;安全审查→安全审计 |
《个人信息保护法》 | 个人信息权益保护 | 告知-同意/最小必要→脱敏策略;删除权→数据退役安全 |
等保 2.0 | 系统层面的安全 | 网络安全防护→安全防护的基础设施支撑 |
DSMM | 组织过程成熟度 | 安全过程能力→与DCMM安全域在组织维度互补 |
从企业合规管理的角度看,这四项制度构成了一个较为完整的数据安全治理框架。DCMM 2.0 安全域在其中扮演的角色,是将分散在各个法规和标准中的安全要求整合为统一的、可评估的能力成熟度标尺。
三条法规与 DCMM 2.0 安全域的叠加逻辑可以这样理解:《数据安全法》定义了"要做什么"(分类分级、安全审查),《个人信息保护法》补充了"对个人数据要做到什么程度"(告知-同意、最小必要、删除权),等保 2.0 提供了"在系统层面怎么防护"(技术基线),DSMM 补充了"组织过程怎么管"(过程成熟度)。DCMM 2.0 安全域将这些分散要求整合为一套可评估的能力标尺,三根支柱分别对应:制度合规(合规管理)、技术运转(安全防护)、可追溯验证(安全审计)。
DCMM 2.0 沿用了五级成熟度模型(L1 初始级至 L5 优化级),安全域在每个等级的要求呈现明显的递进特征。理解这一递进逻辑,有助于企业在评估准备中合理设定目标等级和建设节奏。
等级 | 安全域核心要求 | 关键特征 |
|---|---|---|
L1 初始级 | 无正式的安全管理流程,安全活动以临时应对为主 | 制度缺失、管理依赖个人经验 |
L2 受管理级 | 项目/部门级安全管控,已建立基本分类分级制度 | DCMM 2.0 评估基准等级 |
L3 稳健级 | 组织级安全制度完善,安全防护措施持续运行,审计日志完整可检索 | 多数企业的目标等级 |
L4 量化管理级 | 安全指标量化管理,引入人工智能等先进技术辅助安全风险识别和审计分析 | 量化指标驱动,审计覆盖率目标≥95% |
L5 优化级 | 安全策略自适应优化,安全事件自动化响应与持续改进 | 行业标杆,安全能力内嵌于组织文化 |

从 L2 到 L3 的跨越,是大多数建了数据中台的企业面临的核心挑战。L2 阶段的安全特征是"制度已建立、工具已部署",但制度和工具之间是松耦合的——分类分级制度可能是一份 Word 文档,访问控制可能依赖 DBA 手工配置,审计日志可能存在但无人定期审查。L3 要求的是制度、工具和执行三者形成闭环运转:分类分级结果自动同步到访问控制系统,脱敏策略依据分类标签自动应用,审计日志不仅记录操作还支持按场景检索和生成定期报告。
从 L3 到 L4 的跨越,核心变化在于管理的量化程度和技术手段的先进性。DCMM 2.0 在安全域的 L4 级别明确提出引入人工智能等先进技术——这一要求在 1.0 版本中并不存在。具体而言,L4 级别期望企业具备基于 AI 的异常行为检测能力(例如识别偏离正常模式的大规模数据导出)、安全事件的自动化分级与响应、以及审计覆盖率和响应时效等量化指标的持续监控。
值得留意的一个行业观察是:安全域的成熟度提升对组织层面的依赖远大于技术层面。从 L1 到 L2 可能需要一次分类分级咨询项目,从 L2 到 L3 需要的是组织层面的安全制度和执行文化的建设,从 L3 到 L4 才进入技术驱动的量化管理阶段。对于多数处于 L2 阶段的企业而言,在组织和管理层面补齐短板,比急于引入 AI 驱动的安全工具更为紧迫。
基于以上分析,企业针对 DCMM 2.0 安全域的评估准备,较为稳妥的路径可以按以下四个阶段推进。
安全合规的起点是知道"要保护什么"。这不仅是列出数据库和表的清单,更需要建立数据资产与安全等级的映射关系。实践中,许多企业的数据资产目录和安全分类分级是两套独立维护的清单,导致"这张表在资产目录里标注为'核心业务数据',在安全分类分级里标注为'内部'"的冲突情况。DCMM 2.0 评估师关注的就是这种不一致——它反映的是数据治理和安全治理的割裂。
江苏某地区数据局的共享交换平台在建设中曾面临类似问题——各部门提供的数据未进行统一的分级标识,导致共享过程中的安全管控只能按"部门级"而非"数据级"处理,存在合规不足的风险。后续通过建立统一的数据资产分类分级规则,将安全标签与数据目录关联,实现了数据共享时的分级管控。
安全制度的建设需要跳出"IT 部门写一份安全管理办法"的惯性思维。DCMM 2.0 评估关注的是安全制度在组织层面的落地情况——安全责任人是否在组织架构中有明确定位、安全制度是否经过跨部门会签和定期评审、安全培训是否覆盖全员而不仅是技术团队。
一个常被忽略的要点是:数据安全不是技术部门一家的事。《数据安全法》要求的"数据安全负责人"应在组织中有实质性的决策参与权,而不是IT部门一名高级工程师的兼职头衔。在实践观察中,安全合规准备的薄弱环节往往不是技术工具的采购和部署,而是安全责任的分配——当安全制度仅停留在IT部门内部发文层面,在真正面对评估时,涉及业务部门的数据处理活动的安全合规性几乎无法举证。
在制度和组织基础之上,技术层面的安全能力建设需要覆盖三个核心维度:
分类分级的技术承载:分类分级制度要落地,平台需要提供规则引擎——允许按业务类型、数据来源、字段内容等多种维度定义分级规则,并在数据入仓时自动打标。标签需要贯穿数据流转的全链路——数据从源系统进入中台被标记为"机密",那么基于该数据生成的衍生表和共享接口都应继承相应标签。
安全防护的日常运转:权限管控(行列级访问控制)、数据脱敏(动态/静态)、传输与存储加密——这些是安全防护的基础能力。值得强调的是,安全策略需要支持"场景化"配置。同一个数据集在内部BI分析、跨部门协查、对外共享三种场景下,脱敏策略应具备差异化配置能力——这是 DCMM 2.0 安全防护能力考察中的高频关注点。
安全审计的制度化运行:审计不仅是日志的存储,更是可操作的管理闭环。平台需要提供审计日志的统一检索、异常操作的自动告警、定期审计报告的自动生成。从实际操作来看,评估师在安全审计环节往往会提出"最近三个月的审计报告""上一次审计发现问题的整改记录"等证据要求——这些不是临时能从日志中拼出来的。
在方法论层面,"理采存管用"五阶段模型为数据安全治理提供了一个可操作的框架:理(梳理数据资产和安全需求)→ 采(采集多源数据并打标)→ 存(分区分级存储与加密)→ 管(建立分类分级、访问控制、脱敏加密、审计日志的一体化管控)→ 用(安全地支撑数据应用与共享)。市场上已出现支持此类方法论闭环的产品,其安全模块通常集成分类分级规则引擎、敏感数据自动识别、行列级权限管控和全链路审计追踪等能力,并通过多类精细化角色实现从数据生产到消费的权限管控。

DCMM 2.0 安全域评估中最具挑战性的环节,是将上述所有安全能力"打包"成可举证的证据链条。从实操经验来看,审计证据链的关键不在于证据的量级,而在于逻辑闭合:分类分级制度 → 对应的平台规则配置 → 按规则执行的安全管控记录 → 安全事件的审计日志 → 审计发现的问题记录 → 整改措施和复核确认。这六个节点中的任何一个断裂,评估师都会标记为"安全管控未形成闭环"。
一个值得参考的做法是:在评估准备阶段,先从一个业务域入手,完整验证上述六个节点的证据可用性,修复断裂环节后再扩展到全业务域。相比全面铺开、每处都"差不多"的策略,这种"先跑通一条完整证据链再推广"的做法在评估中更具可信度。数据不出域、全系私有化部署是安全合规的底线保障,也是确保审计证据不被外部环境干扰的基础前提。
DCMM 2.0 九大能力域与方法论的三层映射可以概括为:底层是九个能力域(数据战略、数据架构、数据标准、数据质量、数据安全等),中层是方法论框架(理采存管用五阶段闭环),上层是产品模块(治理域、集成域、存储域、管理域、应用域等)。安全域在这个体系中贯穿"管"阶段的核心位置——分类分级嵌入"理"阶段的数据梳理,访问控制和脱敏嵌入"存"阶段的数据存储,审计日志嵌入"用"阶段的操作追踪,形成安全管控的全链路覆盖。
Q1:DCMM 2.0 安全域显著增强,是不是意味着企业应该将安全域作为贯标准备的第一优先级?
安全域的提升依赖基础的完善——分类分级需要数据资产目录的支撑,访问控制需要数据标准和质量规则的定义,审计追踪需要元数据管理的配合。如果企业的数据架构和数据资产能力域还处于 L1-L2 水平,直接冲刺安全域到 L3 的难度较大。较为稳妥的做法是将安全域并行推进,在评估准备的时间规划中给安全域留足证据积累的周期——安全域的证据依赖日常运转而非突击补齐。
Q2:已经通过了等保 2.0 三级和 ISO 27001 认证,DCMM 安全域还需要单独准备吗?
等保 2.0、ISO 27001 和 DCMM 安全域的评价维度存在本质差异:等保考察的是系统层面的网络安全防护能力,ISO 27001 考察的是组织层面的信息安全管理体系,DCMM 安全域考察的是数据管理语境下安全能力与数据治理体系的融合程度。三者在底层安全能力(如访问控制、加密、日志审计)上有重叠,但评估证据的类型和颗粒度不同——通过了等保不等于 DCMM 安全域可以"免检",反之亦然。
Q3:安全审计在 DCMM 2.0 评估中怎么举证才算充分?
充分的安全审计举证应覆盖三个层次:第一,审计日志的完整性——是否覆盖了全部数据操作类型(访问、修改、导出、删除)和全部受管控的数据资产;第二,审计日志的可操作性——评估师是否可以按业务维度(如"某部门")和时间范围进行快速检索;第三,审计闭环的记录——是否定期生成审计报告、审计发现的问题是否有对应的整改记录和复核确认。多数扣分出现在第三个层次——有前两个层次的材料但缺闭环。
Q4:分类分级制度落地最难的一步是什么?技术工具能解决吗?
分类分级制度落地的核心难点不在技术层面,而在"分级标准如何与动态变化的业务数据保持同步"。数据的敏感级别不是一成不变的——一个数据集在某个业务场景下是"内部级",当它作为统计结果对外发布时可能变成"公开级",当它关联了个人信息后又可能变为"机密级"。单纯依靠一次分类分级咨询项目产出的静态清单,几个月后就会与实际业务脱节。技术工具的价值在于将分类分级规则自动化执行并与数据资产目录联动更新,但工具的上限取决于组织是否建立了维护分类分级规则的常态化流程。
DCMM 2.0 将数据安全域的要求显著增强,这一调整反映了数据治理领域一个正在深化的共识:安全不是数据管理的附加属性,而是数据管理活动本身必须内建的能力。从数据安全法到个人信息保护法,从等保 2.0 到 DSMM,法规和标准的叠加正在将数据安全合规从"可选项"推向"基础门槛"。
对企业而言,面对 DCMM 2.0 安全域的准备,关键不在于投入多少预算采购安全工具,而在于能否将安全能力嵌入到数据治理的日常运转中——分类分级随数据资产更新而动态维护,防护策略随业务场景变化而持续调整,审计日志不仅记录问题更驱动改进。安全能力的成熟度,本质上反映的是组织将合规要求转化为管理实践的深度。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。