DCMM 3 级逐域落地：八个能力域要什么证据

先说结论：DCMM 3 级不是"每个域都写一份制度"。真按这个思路准备，文件会堆成一座小山，现场一问照样塌。3 级的实质是八个能力域各自拿得出"制度 + 执行 + 结果"三件套——制度说明应该怎么做，执行记录说明真这么做了，运行数据说明做出效果并且还在继续。只写不做，3 级过不了；做了不写，也过不了，因为拿不出证据等于没做。

判断标准可以简化成一句话：把任意一个能力域单拎出来，能不能在一小时内凑齐"谁定的规矩、这半年怎么跑的、跑出了什么"三样东西。凑不齐，那个域就还停在 2 级。2 级的典型状态是"有人在管"——某个部门有制度、有责任人；3 级的典型状态是"组织在管"——制度成体系、认责到岗位、跨部门流程跑得通、记录有连续的时间跨度。

这篇按能力域逐个拆。每一节都是同一个四段结构：3 级要看什么 → 常见只有 2 级的做法 → 怎么补到 3 级 → 证据清单。写的是通用框架，具体的域内条款、判定尺度、抽样方式，以评估机构当期评估规则为准。本文不涉及具体分值、权重与条款编号，也不对评估结果作任何承诺。

一、数据战略域：从"领导提过"到"有规划、有预算、有年度动作"

3 级要看什么

看的是数据战略是否成文、是否与业务战略对齐、是否被拆成了年度动作。三个要素缺一不可：一份说清目标与路径的战略或规划文件；一套落到年度的计划与资源保障（人、预算、工具）；一条能看出进展的检查线（谁在什么时候看过执行情况）。3 级还要能看到数据组织与职责的安排——数据管理归口在哪个条线、谁对哪类数据负责、有没有把数据工作纳入部门考核。

常见只有 2 级的做法

战略活在会议纪要的一句"要重视数据"里；或者有一份数字化转型规划，但通篇讲系统建设，没有一句话讲数据怎么管；年度计划是项目立项书的拼盘，写着"上数据中台""建主数据"，却不写谁负责、做到什么算完成。培训靠一次宣贯会，签到表都没留。

怎么补到 3 级

把战略从"愿景"改写成"可交付"：目标 → 分年动作 → 责任部门 → 资源 → 检查节点。写法上有个实用技巧——每一条目标后面接一句"今年的具体动作是什么"，接不上的目标就删掉，留着只会在访谈时被追问。战略文件走内部审批发布，年度计划配预算审批，执行检查落进既有例会（不必新设会议，挂到季度经营分析会上更可持续），培训做成有对象、有内容、有签到、有反馈的固定动作。

证据清单

这一域的判断很直白：战略域 3 级要看到的是一份能被年度计划接住的战略，不是一份漂亮的规划文本。战略写了、年度计划接不上、预算里找不到，这一域就还是 2 级。具体判定口径以评估机构当期评估规则为准。

二、数据治理域：治理机制要"开得起会、裁得了事、考得到人"

3 级要看什么

看治理是否实体化运行：有没有分层的数据治理组织（决策层、管理协调层、执行层），各自多久碰一次、议什么事、决议怎么跟踪；制度是不是成框架（总纲 + 分域办法 + 操作细则），而不是散装几份文件；数据认责有没有落到岗位和人；跨部门的数据争议有没有明确的裁决路径；数据工作有没有进考核。

常见只有 2 级的做法

一份《数据管理办法》，一个兼职的数据管理员，跨部门的事靠他逐个去求人。治理委员会存在，只挂在文件上，一年开一次会，纪要写"原则同意"。认责清单写着"财务部负责财务数据"——问财务部谁负责，答不上来。考核表里没有数据这一项，或者有，但从没扣过分。

怎么补到 3 级

四件事按顺序做：定人、定会、定责、定考。定人是把三层组织的成员名单和职责落到任命文件；定会是给出固定节奏（比如管理层季度议事、执行层月度协调），并且每次会议必须有决议和跟踪表——没有跟踪表的纪要在现场几乎不算证据；定责是把数据认责清单做到"数据项—责任岗位—责任人—职责"四列齐全，并让责任人签过字（签字这一步很关键，能同时解决"不知道被认责"这个高频问题）；定考是把一两条数据指标放进部门绩效，并且真的有过评分记录。

制度体系不用一次写全，按"1 + N + M"搭骨架：一份总纲讲组织、职责、流程、考核；N 份分域办法对应八个域的关键活动；M 份操作细则和表单落到具体动作。先有骨架再长肉，比八份互不引用的文件强得多。

证据清单

治理域是八个域里被问得较多、也容易露底的一域，因为它天然跨部门。一句判断：如果数据相关的跨部门争议仍然只能靠某个人去协调，这个域就还是 2 级。裁决机制的具体形式以本企业治理制度为准，是否符合 3 级以评估机构当期评估规则为准。

三、数据架构域：要分层设计的模型和变更记录，不是一张 ER 图

3 级要看什么

看四样东西：数据模型的分层设计与变更记录（概念、逻辑、物理三层各有产出，模型改动走评审并留版本）；数据分布与流向（数据在哪几个系统产生、流向哪里、谁是源头系统）；集成与共享的管理（接口清单、调用关系、责任归属）；元数据管理（技术元数据、业务元数据的采集与维护，能看出血缘或上下游关系）。还要能看到数据架构与业务架构、技术架构的对应关系——架构不是 IT 自己画着看的图。

常见只有 2 级的做法

手上只有一张多年前画的 ER 图，还是某个系统的局部；接口文档散在各项目组，谁调的谁清楚；元数据是一张 Excel，登记了表名和中文名，字段级信息缺失，而且三个月没更新；模型变更靠开发口头说一句"我加了个字段"。这类状态的特征是：架构信息存在于人的脑子里，而不是系统里。

怎么补到 3 级

从三件小事起步，成本低、见效快：先定命名与分层规范（表、字段、编码怎么起名，概念层/逻辑层/物理层各产出什么），再建接口台账（源系统、目标系统、字段、频率、责任人、变更方式），然后把元数据从系统自动采——手工登记的元数据基本活不过三个月，这是行业的普遍经验。模型变更纳入既有的需求变更流程，评审单上留一句"对数据模型的影响"，比新建一套流程更容易落地。

数据分布图不必画得漂亮，但必须能回答一个问题：某个关键数据项（比如客户、物料、合同）在哪些系统里存在，哪个是源头系统，其余怎么同步。答不上来，架构域的说服力就有限。

证据清单

一句话判断：数据架构域 3 级要看到数据模型的分层设计和变更记录，不是只有一张 ER 图；同时要看到元数据是活的——现场随机点一张表，能查出字段含义和来源。架构域的具体评估着眼点以评估机构当期评估规则为准。

四、数据应用域：应用要有场景清单，价值要有回溯

3 级要看什么

看数据是不是真的被用起来了：有没有一份数据应用场景清单（场景、使用方、数据来源、预期价值、当前状态）；分析结果有没有进入业务决策（决策会上引用过、采纳过、事后复盘过）；数据服务与共享开放有没有目录和使用记录；应用效果有没有回头看过——不是上线就算完。

常见只有 2 级的做法

报表一大堆，但没人说得清哪些在用、哪些没人打开过。业务提需求、IT 做报表，做完发出去，用不用、准不准、有没有改变决策，没人跟。数据分析停在"出一份月报"，月报发在群里，没人回复。开放共享就更少：数据要么不出去，要么出去了没人管口径。

怎么补到 3 级

做法是把"应用"当成一个有前中后的过程管理：前有场景清单和优先级（哪个业务痛点、用哪些数据、预期什么效果）；中有需求、开发、验收的记录（谁提的、验收标准是什么、谁签的收）；后有使用跟踪和价值回溯（访问量、引用情况、业务侧反馈、有没有导致某个决策或流程改变）。

场景清单宁可短，也要真。挑三到五个业务方愿意开口讲成效的场景，把过程记录补齐，比列二十个没人用的场景有说服力。数据服务要挂目录：谁能申请、怎么申请、给了谁、调用了多少次，这四问有答案，开放共享这块就立住了。

证据清单

判断句：数据应用域 3 级看的是"数据改变了什么"，不是"做了多少个报表"。场景数量不构成能力，能被业务讲出来、能追溯到一次决策或一次流程优化的场景才构成能力。场景的取舍与判定以评估机构当期评估规则为准。

五、数据安全域：分级分类要落到字段，权限和日志要查得到

3 级要看什么

看分级分类是否落到具体数据项（不是一份原则性文件，而是哪些表哪些字段属于哪一级）；看访问控制是否按角色和审批走（谁能看、谁批的、多久复核一次）；看审计日志是否留存可查（敏感数据的访问、导出、修改有记录）；看安全策略、应急预案与演练；看对外共享与委托处理有没有评估和协议约束。

常见只有 2 级的做法

有一份信息安全制度，附件里的分级分类表列了"公开/内部/秘密"三档，但从没落到具体系统字段；权限靠 DBA 手工开，开完没有审批单；日志开了但只存几天，出问题查不到；应急演练是纸面方案，没跑过；数据给出去了，签的是通用保密协议，没写数据用途和销毁要求。

怎么补到 3 级

两条主线：把分级落到资产上，把权限落到流程上。前者是给关键数据项打级别标签，并与数据资产目录对齐——目录里的每个数据项都能看到级别，这一条做好了，安全域和数据架构、数据标准就串起来了。后者是把开权限这件事从"找人"变成"提单"：申请、审批、开通、定期复核四步，每步留痕；敏感数据的导出单独设卡。

日志这块有个现实问题：很多企业有日志但不会用。3 级看的不是"有没有开日志"，而是"查不查得到、查过没有"——能不能现场按人、按表、按时间段查一次访问记录，以及过去有没有真的做过一次日志核查。演练同理，一年至少跑一次，有方案、有过程、有结论、有改进项，纸面演练在现场很难算数。

证据清单

一句话判断：数据安全域 3 级要能看到"这条数据是什么级别、谁能动、动过没有"，三问都有答案才算落地。若同时在做 DSMM 或 ISO 27001，分级分类、权限矩阵、日志这些底稿可以共用，但评估口径要分别对齐。安全域的具体判定以评估机构当期评估规则为准。

六、数据质量域：规则要成库，问题要闭环，结果要有人看

3 级要看什么

看四件事：质量需求来自业务（不是 IT 自己拍几条规则）；规则成库（规则、校验逻辑、适用范围、阈值、责任人）；检查有节奏（按周期跑，有检查报告，覆盖关键数据）；问题闭环（发现、分派、整改、验收、复盘，一个都不少）。还要看质量结果有没有被使用——有没有质量看板、有没有在例会上被讨论过。

常见只有 2 级的做法

业务说"数据不准"，IT 去查，查完发现是录入问题，让业务改一改，事情结束，没有记录。同一个问题三个月后再出现，再查一遍。特征是没有规则库、没有台账、没有闭环——质量工作全靠个人经验，人一换就断。也有企业买了质量工具，配了十几条规则，但规则是谁定的、阈值为什么这么设，答不上来。

怎么补到 3 级

按"选关键数据 → 定规则 → 排检查 → 建台账 → 进例会"五步走。选数据要窄：先覆盖三到五个影响业务的关键数据项（客户、物料、合同、财务科目这类），把闭环跑通，比全量铺开有用。定规则要和业务一起定，问法很具体——"这条数据什么样算错"，业务答得出来的才是真规则。

问题台账是这个域的核心证据，格式不用复杂，但必须有几列：问题描述、发现时间、影响范围、责任人、整改措施、完成时间、验收人。台账里有跨月的、已闭环的条目，这一域基本就站住了。质量看板不追求炫，能把"本期检查了多少、发现多少、闭环多少"说清楚就够。

证据清单

判断句：数据质量域 3 级的标志不是"数据很干净"，而是"问题能被稳定发现并闭环"——数据不可能没问题，能不能形成发现与整改的循环才是能力。规则数量、检查频次的具体要求以评估机构当期评估规则及本企业制度为准。

七、数据标准域：口径要统一到能对账，标准要落到系统字段

3 级要看什么

看标准体系是否覆盖四类对象：业务术语、主数据、指标数据、数据元（含编码）。看标准是否有完整的编制—评审—发布—贯标流程，看标准有没有落到系统里（字段命名、码表、指标取数逻辑能对上标准），看标准变更是否受控（改了标准，下游报表和接口跟不跟）。

常见只有 2 级的做法

有一份业务术语表，几十条，编完就放进共享盘。指标口径散落在各部门的报表说明里，同一个"活跃客户"在销售、财务、运营三张表里是三种算法，开会时先花半小时吵口径。主数据靠人工比对，同一个供应商在系统里有三个编码。这类状态的特征是：标准是文档，不是约束。

怎么补到 3 级

顺序上有个务实的选择：先做指标口径，再做主数据，然后铺到数据元。原因是指标口径是业务争议的集中地，把这块统一了，跨部门配合的意愿会明显上来；主数据治理见效直观（一物一码），容易拿到业务支持；数据元与编码标准偏底层，放在后面做，可以借前两步的机制顺势推进。

贯标是这一域的分水岭。标准发布不等于贯标：要能拿出"标准里的字段名和系统里的字段名对应关系"，以及"新系统上线前按标准做过检查"的记录。每个指标要有统一定义——定义、计算公式、取数范围、责任部门，四样齐全，才算能对账。

证据清单

判断句：数据标准域 3 级的硬指标是"能不能对账"——同一个指标，两个部门报出来的数一致，并且能说清口径从哪来。标准数量没有意义，落地比例才有意义。标准的覆盖范围与判定尺度以评估机构当期评估规则为准。

八、数据生存周期域：从需求到退役，每个环节都要有"谁在管、怎么留痕"

3 级要看什么

看数据从需求、设计与开发、运维、归档到退役的每个环节有没有管理要求与责任人。重点有三处：数据需求是否纳入需求管理（而不是谁喊得响谁先做）；设计与开发阶段有没有数据设计内容（模型、口径、质量校验、安全级别）；归档与销毁有没有审批和台账（这是被查得较多、又常被忽略的一段）。

常见只有 2 级的做法

系统上线有流程，系统下线没人管——老系统停了，数据留在库里，谁负责、留多久、能不能销毁，没人说得清。归档靠运维习惯，删数据靠 DBA 口头确认，没有审批单。数据需求混在业务需求里，没有单独的数据影响评估。这类状态的特征是：前半段（上线）有流程，后半段（归档、退役）是空白。

怎么补到 3 级

补的重点通常不在开发流程，而在末端两件事：建归档清单（哪些数据、存在哪、保留多久、谁能取），建销毁与退役流程（申请、审批、执行、记录，以及退役系统的数据处置说明）。这两件事一旦成文并跑过一轮，生存周期域的完整度会明显改善。

前端可以做两处低成本嵌入：一是在需求模板里加一栏"涉及哪些数据、影响哪些下游"；二是在设计评审里加一条"数据模型与口径是否已对齐数据标准"。加两栏的成本很低，但能让生存周期域和数据标准、数据架构两个域互相作证。

证据清单

判断句：数据生存周期域 3 级看的是闭环——一条数据从提出需求到销毁，中间每一步都能找到责任人和记录。只做前半段、末端空白的，仍然只能算 2 级。归档与销毁的具体保留要求以本企业制度及主管方规定为准，是否符合 3 级以评估机构当期评估规则为准。

九、跨域的三件通用证据：没有这三样，八个域都会掉

八个域逐条补完之后，还有一层共性要求。评估现场真正决定"像不像 3 级"的，往往不是某一域写得多细，而是这三件事在八个域里是不是都成立。

这三件事的检验方法很简单，也很有用：随便挑一个域，抽一条制度要求，往下追三层——系统里有没有对应动作、台账里有没有对应记录、记录里的人能不能讲清为什么这么做。追得通，这一域就是 3 级；断在哪一层，就补哪一层。追不通的原因通常只有三个：制度是借来的、系统没配、记录没留。

还有一个容易忽略的点：跨域的一致性。数据安全的分级分类要和数据资产目录对得上，数据标准的指标口径要和质量规则对得上，数据治理的认责清单要和安全域的权限复核人对得上。八份材料各自完整、彼此打架，现场一样会被追问。归集材料时建议先做一张"域—材料—责任人"的对照表，再横向核一遍人名、系统名、岗位名、日期。具体核查方式与抽样口径以评估机构当期评估规则为准。

十、行动清单：按这个顺序推，返工少一半

十二条，按顺序过。每条都要能给出具体答案再往下走，答不出来的那条就是本周的待办。

• ⬜ 我清楚 3 级是目标还是过程——招标或考核文件里写的等级要求，原文是什么
• ⬜ 八个能力域每个都有对接人，不是一个人扛八个
• ⬜ 每个域我都能说出制度、执行、结果三件套各是什么，而不是只有一份制度名
• ⬜ 我做过一轮逐域差距盘点，产出的是具体条目，不是"基本符合"
• ⬜ 制度体系有总纲 + 分域办法 + 操作表单的层次，彼此引用得上
• ⬜ 数据认责清单到岗位到人并有签字，被认责的人知道自己被认责
• ⬜ 数据资产目录里的表和字段，能在系统里逐条核对到
• ⬜ 关键记录有跨月甚至跨季的连续性，不是集中补的
• ⬜ 质量、安全、标准三个域各有自己的闭环证据（问题台账、权限复核、贯标检查）
• ⬜ 生存周期域的归档与销毁有台账和审批，不是空白段
• ⬜ 八个域的人名、系统名、岗位名横向核过一遍，没有互相矛盾
• ⬜ 我准备了能被访谈的人：治理牵头人、各域对接人、以及能讲清投入的高层

能打勾的不到六条，说明现在还不适合约评估——先把三件套跑出来，比先约现场再补证省力得多。八个域里如果只补了治理、安全、质量三个，其余五个空白，缺的不是深度而是覆盖面，这一条在盘点阶段就要处理掉。

结语：3 级考的是"跑得住"，不是"写得好"

把八个域摊开看，会发现 3 级的要求高度一致：有成文的规矩、有真在跑的流程、有留下来能查的记录、有能讲清楚的人。八个域的区别只在于对象不同——战略域的对象是目标和资源，治理域是组织和制度，架构域是模型和元数据，应用域是场景和价值，安全域是级别和权限，质量域是规则和闭环，标准域是口径和落地，生存周期域是环节和末端。

所以准备顺序建议是这样：先逐域盘点三件套 → 补制度骨架 → 把动作嵌进系统或流程卡点 → 让机制跑够一段时间、把记录自然长出来 → 再谈评估排期。反过来，先写八份制度、再去找记录凑，是返工常见的起点——因为制度写的是"应该"，记录反映的是"实际"，两者之间的差距迟早要补。

延伸阅读：DCMM 的整体流程与返工点见 DCMM 评估全流程；概念与等级划分见 DCMM 百科页；数据安全专项见 DSMM 实务 与 DSMM 百科页；信息安全管理体系见 ISO 27001、ISO 20000 与 CCRC 信息安全服务资质；体系类认证的整体地图在 体系认证总览，服务范围见 认证服务，同类项目的过程记录可参考 客户案例，自查工具在 认证速查。

▍八个域里哪几个还只有制度、没有记录？留言或私信我，备注"DCMM 3 级逐域"，我发你一份按域拆开的证据对照表，可以先自己盘一遍再决定要不要启动。

普华智科 / CertFastLine 普华认证｜出口认证 & 检测 & 管理体系咨询 本文为合规科普参考，非法律或评估结论；等级划分、能力域要求、评估程序、机构受理范围、费用与周期以主管机构当期文件及承担评估的机构要求为准