DCMM Assessment: What to Prepare and Where It Stalls

Bottom line first: the hard part of a DCMM assessment is not writing documents, it is whether what you say and what you do are the same thing. The assessment looks at evidence — policy documents, process records, platforms and tools, the data asset catalogue, and actual operating data. Documents can smooth the wording over; the evidence chain breaks it open: the approval step written into the policy, is there a matching step in the system? The data table listed in the catalogue, can it be found in the database? The indicator definition on the report, does it match the definition in the policy? If those three questions cannot be answered, however thick the material is, it is only a stack of paper.

DCMM (Data Management Capability Maturity Assessment) sorts an enterprise's data management capability into 5 levels (1 Initial, 2 Managed, 3 Defined, 4 Quantitatively Managed, 5 Optimizing), covering 8 capability domains: Data Strategy, Data Governance, Data Architecture, Data Application, Data Security, Data Quality, Data Standards and Data Lifecycle. The assessment is carried out by a qualified assessment body; a self-assessment or gap analysis usually comes first, and the formal assessment follows.

This article follows the order "set the level first → how the eight domains map onto departments → how to run the self-assessment → what the formal assessment examines → materials checklist → timeline and investment → rework points → how to combine with DSMM / ISO 27001". No figures are given for fees, timeline or auditor days — all of that is subject to the assessment body.

1. Set the level first: why many companies aim at Level 3

On the level question, start with where the requirement comes from: the tender document, the group's performance assessment rules, or an internal requirement around capitalising data assets. Prepare to whatever level is written down; where nothing is specified, preparing for Level 3 is usually the pragmatic choice.

Level 3 is the watershed because what it proves is different: Levels 1-2 prove "someone is managing it", Level 3 proves "the organisation is managing it" — a unified set of policies, data accountability that lands on named posts, processes that work across departments, and operating records with a checkable time span. Levels 1-2 earn limited extra credit in tenders not because the level is low, but because it states too little: one department has a policy, and the next department may not.

Two reminders. First, higher is not automatically better. Levels 4 and 5 call for quantitative indicators and evidence of continuous optimisation; forcing them without several years of data accumulation gives a poor return on investment. Second, no body should promise in advance which level you will reach — whether the level is reached is judged independently by the assessment body under the assessment rules, and this article makes no commitment about the outcome either.

2. How the eight capability domains map onto departments

This is one of the questions asked frequently during implementation: the 8 domains sound like the business of 8 departments, while in practice one or two people are pushing it. Draw a mapping table first, placing each domain onto a department and onto evidence, and only then can responsibility be divided.

The table has to be read correctly: "owning department" is where responsibility lands, not an organisational design recommendation. The actual pattern in many companies is that data governance and data standards are led by the data management or digital line, data architecture, data security and lifecycle sit on IT, data application sits on the business side, data quality is jointly managed by both sides, and data strategy is decided by the executive in charge. How it is divided is subject to the company's current division of responsibilities, but every domain needs one clearly named contact, even if the role is part-time.

One more reminder: all 8 domains must be accounted for. They can be covered lightly, but not left blank. Do only data governance and data security and say nothing about the other six, and the assessment will ask "how were the other domains considered" — answering "we have not done that yet" is also an answer, but it has to explain the boundary and the plan, rather than being caught out as an omission.

3. How to run the self-assessment / gap analysis

The self-assessment is not about awarding yourself points; it is about finding the gaps. There are three steps:

1. Define the scope. Which business lines, which systems and which organisational units are included in this assessment. A wide scope means more evidence to fill in; too narrow a scope cannot support a judgement of "organisation-level".
2. Work through each domain. Ask three questions of every clause in the 8 domains: do we have a written rule now? Is it running? What records does running it leave behind? If all three are answered "yes", add one more: where is the evidence, and who can produce it?
3. Produce the gap list. Classify the gaps by nature, because different types are closed in different ways and at a completely different pace — that classification is the real output of the self-assessment.

One imbalance shows up often in self-assessment reports: all 8 domains are written up as "largely conformant", and not one real gap is found. Such a self-assessment falls apart at the first sample taken on site — not because the level is not there, but because the self-assessment failed to do its job of finding problems early. The other way round, a self-assessment that finds twenty or thirty real gaps, each with a way to close it, an owner and a target date, is a useful document.

Also, align the gap analysis criteria with the assessment body. On the same requirement, different assessors may look from different angles; asking about the judgement criteria, the sampling scope and the form of evidence at the self-assessment stage saves far more effort than explaining on site. The specific requirements are subject to the current assessment rules of the body carrying out the assessment.

4. What evidence the formal assessment examines

The formal assessment usually runs in two parts: a document review first, to see whether the material is complete and consistent with itself; then an on-site stage of interviews, sampling and system checks. What is examined falls into five categories.

The on-site stage deserves a paragraph of its own: the assessment asks people, and it asks the people who actually do the work. Who chairs the data governance meeting, how often does it meet, what was discussed last time; how were the problems found by the quality check corrected, and who accepted the fix; why is this indicator defined this way — questions of that kind cannot be passed by memorising the material.

On independence: consulting and assessment are two roles, and the party that helps you build the system should not also be the party that issues the assessment conclusion. With claims of the form "we assess it ourselves and we know where the result will land", ask one question first: which body issues the conclusion, and where can its assessment qualification be checked. The list of assessment bodies and the scope of their qualification are subject to the information published by the competent authority for the current period; this article lists no names.

5. Materials checklist: prepare for "citable from three places"

More material is not better. There is only one test: can a single piece of material be cited at the same time by a policy clause, a system record and an operating ledger? Only what closes the loop counts; a pile of standalone documents earns nothing.

On the order of preparation, work backwards: take stock of the existing records first, then fill in the policies, then the platform. Look at how the data actually flows and what it leaves behind, then go back and write the policies as "what we are already doing" — that way the material does not split into two versions of reality. Writing the policies first and then hunting for records to match them is a frequent starting point for rework.

6. Timeline and what the investment consists of

The whole flow runs roughly like this: the first four steps sit inside the enterprise, the last four involve the assessing party:

No month count is given here, for a practical reason: it depends on four things — how large the business and system scope in the assessment is, what baseline the existing policies and records sit on, how many months of operating records have to be accumulated, and the assessing party's scheduling. Companies with a good baseline have smaller gaps and fewer things to fill in, so the pace is naturally quicker; for a company starting from zero, the step of "getting the policies to really run and leave records" cannot be skipped. The specific schedule is subject to the assessment arrangements of the assessment body.

The investment usually consists of four parts: assessment-related fees (charged by the assessment body under its own rules, and related to the assessment scope and the size of the company), consulting fees (self-assessment, policy review, material preparation, interview rehearsal), internal effort, and tool purchases where necessary. Each amount is subject to the quotations of the assessment body and the service provider, and any fixed figure given in advance is worth checking against its definition first.

What tends to be underestimated is internal effort. This kind of work usually needs one lead (from the data management or digital line), one contact for each of the 8 domains, and a supporting person on the IT side, committed throughout the preparation period rather than outsourcing the whole thing to a consultant. How well the internal effort is staffed often affects progress more than which body is chosen — because on the interview question, a consultant cannot stand in.

7. Common rework points

• The policies are "borrowed". The template is obvious; department names, system names and approval levels do not match the company. The assessor can see at once that this material has never landed in this organisation.
• Policies and execution are two different things. The policy states three levels of approval while the system has one; the policy requires a monthly quality check and no check record can be found in the workbench. This is one of the categories asked about frequently.
• The data asset catalogue is "made up". Its tables cannot be found in the system, the field names do not match the database, and the named owner does not know they were named. The catalogue is something to be sampled and checked, not decoration.
• Dates that run backwards. A policy is released later than the execution records it governs, or a record carries a version number that has not yet taken effect. This kind of hard defect is very hard to explain.
• Only three domains were done. Data governance, data security and data quality are written up at length, and the other five are blank. What is missing is not depth, it is coverage.
• Treating the self-assessment as the conclusion. Everything conforms in the self-assessment, then the first sample on site collapses. The value of a self-assessment lies in finding things early, not in looking good.
• Handing all of it to an outside party. The consultant knows the system better than the employees, who cannot answer "who defined this data quality rule, and how often does it run". The interviewees have to be the people who really do the work.
• Stopping once the certificate is in hand. The assessment conclusion has a scope of application and a validity period; if the mechanism then stalls and the records break off, the next assessment is effectively starting over and the earlier investment is wasted. The specific requirements for re-assessment and maintenance are subject to the current rules of the issuing body.

8. How to combine it with DSMM and ISO 27001

These three often appear in the same tender document for a data-related project, but they examine three different things and do not substitute for one another.

In practice there are three points of experience:

• DCMM and DSMM can be combined, and the crossing point is the Data Security domain. The two assessments overlap on data classification and grading, access control and audit logging, so the policies can share one base document; but the assessment criteria have to be prepared separately — DCMM looks at where data security sits within the data management system, DSMM looks at the maturity of the security capability itself. The same batch of records supports two conclusions; what you save is duplicated labour, not duplicated evidence gathering.
• ISO 27001 is another dimension; do not treat it as a substitute for DCMM. ISO 27001 governs the risks and controls of information assets and can cover part of the data security evidence, but it does not touch the management maturity of data standards, data quality, data architecture or data lifecycle. Conversely, a company that has done ISO 27001 can reuse its classification and grading, permission matrix and audit logs directly in the Data Security domain, which makes the start lighter.
• Sequence by working backwards from the tender date, not from "how complete the system looks". If the tender document treats DCMM as an admission item and ISO 27001 as a scored item, secure DCMM first; if both are admission items, the usual route is to do ISO 27001 first to put the system skeleton in place (policy, document control, internal audit, corrective action), then build up to DCMM's capability depth, which reuses more.

As for which certificates and which level a particular tender actually requires, the wording of the tender document itself governs — do not guess from industry habit. On how ITSS, CMMI, DCMM and CSMM differ in positioning, this article sets out the comparison; for the concepts and level definitions of data management, see the DCMM knowledge base page; the overall map of management system certification is on the management systems overview, and the information security side is covered by ISO 27001 and ISO 20000.

Action checklist

Go through this in order before you start, and move on only when every line has a concrete answer:

• ☐ I can state clearly where the target level comes from — tender document, group performance rules or internal requirement, and what the text actually says
• ☐ I know which business lines, systems and organisational units this assessment covers, and I can draw the scope
• ☐ Each of the 8 capability domains has its own contact person, rather than everything resting on one person
• ☐ We have run a round of self-assessment or gap analysis and can produce twenty or thirty specific gaps, rather than everything conforming
• ☐ We have a policy framework covering the 8 domains, with versions, effective dates and a match to our structure
• ☐ We have a data asset catalogue, and its tables and fields can be checked in the system
• ☐ Our platform or tools are producing real data (metadata, quality, permissions, audit), not merely purchased
• ☐ We have prepared people who can be interviewed: the governance lead, the contact for each domain, and a senior manager who can explain the investment
• ☐ I am clear on the sequence of DCMM against DSMM and ISO 27001, and on which material can be shared
• ☐ I understand that the conclusion has a scope of application and a validity period, and we are willing to maintain the mechanism and the records afterwards

If fewer than five of these ten can be ticked, now is not the time to book an assessment — filling in the policies, the catalogue and the operating records first is far faster than booking the on-site days and gathering evidence afterwards. Where things are unclear, you can also contact us directly and go through them line by line.

Conclusion: get the evidence running first, then talk about the level

What a DCMM assessment really tests is consistency: the policies say "how it should be done", the system shows "how it actually flows", the records show "it really was done that way", and the interviews show "the people doing it know why". String the four together and the capability holds; miss one and you have to go back to the business floor to fill it in.

So the order is: set the level and scope first → then run the self-assessment to find the gaps → fill in the policies and the data assets → let the mechanism really run for a period and let the records grow → only then discuss the assessment schedule. Do it in the reverse order, and however complete the material is, it will not survive the on-site interviews and sampling.

▌Not sure whether you need this, or want to know how to sequence DCMM against DSMM and ISO 27001? Leave a comment or message me with "DCMM self-check" and I will send you a domain-by-domain comparison checklist.