DCMM's Five Levels, One by One: What Each Level Reviews and What Evidence It Wants

The five levels at a glance

Start with the whole picture. The way to use this table is not "pick a level and apply", but hold it against the policies and records you actually have, and see which row's description of a state overlaps with the way you work today. The row that overlaps is your real starting point; the row above it is your next target.

Level 1Initial: all you can show is "someone handles it when it comes up"

What is reviewed

The typical state at Initial is reactive response: someone acts only when the business asks, a system fails, or a regulator wants a report. There is no written data management policy, no fixed data owner, and cross-departmental matters move by ad hoc coordination. What the assessment looks at here is not the policy text but repeatability — who handles data-related matters, under what circumstances, and whether the handling is stable. The answer is usually "it differs each time", and that is an accurate picture of Level 1.

One layer in, it looks at whether the boundary is clear: does the company know what data it holds, which systems it sits in, and which steps nobody owns at all. At this stage the material is not there to prove capability but to state the present position clearly. State it clearly, and the later gap analysis has a starting point; fail to, and every step upward lands on nothing.

Who it fits

Companies with a modest volume of data, no external acceptance scenario, and a first attempt at taking stock; group units asked to run a baseline survey without pursuing a level yet; and organisations planning to move in stages, wanting the present position and the gaps written down before a project is set up. In practice there is little demand to apply for Level 1 as a target, because it explains little in tenders and performance assessment — not because the level is low, but because it proves so little: whoever runs into the problem deals with it, and the same answer may not hold in the next department.

How to organize the evidence

• Policy: at this stage many companies have no standalone data management policy, and what can be found are clauses mentioning data here and there in information security or IT operations policies. Do not force a document into existence; a three-column table of "what exists, what is missing, where the boundary lies" is more useful than a policy assembled for the occasion.
• Process records: tickets, incident sheets, emails and minutes from ad hoc coordination. Their value is in showing the type of problem and how it was handled, not in being complete; one record that explains who found it, who handled it and with what result beats a stack of ticked forms.
• Platforms and tools: databases, reporting tools, backup tools — the basics. Register purpose, owner and scope of use; there is no need to dress them up as a "data management platform", since a description that does not match the thing itself collapses at the first question on site.
• Data assets: a list of systems and of the main business tables. At this stage there is usually no classification or grading and no accountability at post level, and marking that honestly is more convincing than adding a column under duress.

Common return reasons

• Treating "we bought a system" as "we do data management". The material is all system lists and feature descriptions, with no concrete management action anywhere, so no judgement can rest on it.
• Everything written as "the IT department is responsible". No post, no name, no division of work — ask "who did this" during verification and the chain snaps.
• Problems handled without a trace. The account can only come from memory; however vividly it is told, it cannot be traced or checked.
• Level 2 or even Level 3 policy documents brought over wholesale. This level is where "talking it up" does the damage: the policy says a meeting is held quarterly, yet not one set of minutes can be produced — and the genuine starting position has been lost as well.

Level 2Managed: from "whoever hits it handles it" to "someone owns it, there is a rule to follow"

What is reviewed

Level 2 reviews a controlled state inside a bounded scope: key data activities have an owner — data entry follows a convention, reporting has a named home, access is granted with approval, quality issues are followed up. The assessment looks at three things: is the rule written, is the owner clear, and does the action repeat stably inside a fixed scope. Where all three hold, the level stands.

It also looks at the cross-departmental part: when the same data passes between two departments, are definitions, responsibilities and dispute handling agreed. This is where many Level 2 companies break — not because nobody is in charge, but because each side is in charge of its own segment and the seam is in charge of nobody. It also explains why Level 2 material so often looks like "every file passes on its own, and the set does not add up".

Who it fits

Companies with department-level data rules and a data administrator or data owner post; organisations whose business systems are fairly mature and whose data volume has begun to affect daily operations; units treating Level 2 as a transition and planning to move to Level 3 within a period; and group subsidiaries that only need to show that local management within their own unit holds. One caution: where the external requirement is a proof of organisation-level capability, Level 2 often falls short, and effort is better spent on cross-departmental mechanisms than on polishing Level 2 material repeatedly.

How to organize the evidence

• Policy: department-level rules, job descriptions, operating instructions. These are usually cited only inside the department and lack any link to organisation-level policy, so mark the scope of application when organizing — "this rule applies to department X" survives questioning far better than a vague claim that it covers the whole company.
• Process records: approvals, checklists, issue lists and monthly reports inside the department. Coverage is limited and the time span is often short, and this is precisely where the gap to Level 3 shows; when filling it, lengthen the period first and discuss widening the scope afterwards.
• Platforms and tools: department-built reports, point tools, or one module inside a system. They produce data but lack a unified view across systems, so state what they do and do not cover when registering them.
• Data assets: department registers, in-system data dictionaries, partial master data lists. Accountability generally stops at the department and has not reached the post — and the thickness of this column often decides whether Level 3 is reachable at all.

Common return reasons

• A department-level rule described as an "organisation-level policy" in the application form. Ask on site whether other departments follow it and there is no answer, and the credibility of the whole file drops with it.
• Accountability parked at department level. The list says "Finance is responsible for financial data", but ask who specifically, and who has signed, and no name can be produced; the person held accountable does not know they were named.
• Records covering a short period, concentrated just before the assessment. The mechanism is not visible as continuous operation, only as something assembled for this exercise.
• The same indicator calculated differently in different department reports, with the difference left unsaid. Two reports set side by side in an interview expose it, and this kind of problem should have been settled during preparation.

Level 3Robust: from "someone owns it" to "policy, process and execution records"

What is reviewed

Level 3 reviews whether organisation-level mechanisms are running: has a unified data management policy system been established and executed; do all eight capability domains get an answer (written lightly is acceptable, left entirely blank is not); does data accountability reach posts and people; do cross-departmental data disputes have a clear route to a decision; has data work entered departmental appraisal; and do operating records continue across months and quarters.

On site, three methods usually cross-check each other: document review to see whether the material is complete and internally consistent; interviews with the people who actually do the work; and sampling in the system on the spot. All three point at one thing — is the process written in the file the same process the business staff describe. If it is, the capability holds; if it is not, the thicker the file the more it looks like another company's material.

Who it fits

Government and central state-owned enterprise data tenders, preparation for putting data assets on the balance sheet, group digitalisation assessment, and companies whose internal data governance has stalled for a long time. The majority of enterprises treat Level 3 as the realistic target for a practical reason: it corresponds to a common acceptance threshold without needing years of quantified accumulation. One thing should be said plainly too: if internal cross-departmental meetings cannot even be convened and an accountability list cannot be signed, the gap is at the execution layer, and getting the mechanism running will cost less than booking an assessment early.

How to organize the evidence

• Policy: three layers — charter, domain-level rules, operating instructions — that cite each other, with version, effective date, and records of issue and communication. The test is not page count but layering and linkage; eight documents that never mention each other are eight islands.
• Process records: governance meeting agendas and decision tracking, signed accountability lists, a register of quality issues from discovery to closure, access requests with approvals and periodic review, standard rollout checks. What matters is continuity and closure, not volume; entries that cross months and have been closed carry the weight.
• Platforms and tools: metadata, master data, quality, access and audit tools must be able to produce operating records and operation logs on the spot. A purchase contract and a screenshot of the interface only prove "bought", not "in use".
• Data assets: the data asset catalogue must reconcile item by item with the systems, classification and grading must reach tables and fields, accountability must reach posts, and sharing and opening must have lists and call records. This is among the items sampled frequently, and a catalogue that is neatly "compiled" still will not survive one click on site.

Common return reasons

• Only governance, security and quality done, the other five domains blank. What is missing is coverage, not depth: with no account anywhere of architecture, application, standards or lifecycle, the overall judgement cannot rise.
• Borrowed policy templates with inverted dates. Department names, system names and approval levels do not match this company; or a policy is issued after the records that execute it, or records cite a version number not yet in force. Such flaws are hard to explain away.
• A data asset catalogue that has been assembled. Tables in the catalogue cannot be found in the system, field names do not match the database, and the person named as accountable does not know they were named — one mismatch in any of the three and this item counts for nothing.
• Records concentrated in the last month or two, and interviewees cannot answer "why". People can recite policy clauses but cannot say what the last meeting discussed or why an indicator is defined that way, and the authenticity of the mechanism is in doubt.

Level 4Quantitatively Managed: from "the mechanism runs" to "how well it runs can be measured"

What is reviewed

Level 4 reviews quantitative management capability: has an indicator system been established covering both the process and the effect of data management; do indicators have clear definitions, calculation rules, baseline values and targets; is there periodic measurement and review; when a deviation appears, is there cause analysis and corrective action, and is there re-measurement afterwards; and are the quantitative results actually used for resource allocation, prioritisation and appraisal.

It also looks at how far the quantification reaches. Indicators in one or two domains while the rest remain qualitative usually will not carry this level, because what is tested is "managing data with data", not "one domain produced some statistics". The test can be put in one sentence: if someone else took over, could they use this indicator set to tell where the problem is now and what to move first. If yes, quantification holds; if not, the indicators are only reports.

Who it fits

Companies that have run steadily for a period with continuous records and accumulated indicators; units whose group appraisal explicitly requires quantified proof; organisations that must explain quality level and management process for balance-sheet treatment of data; and companies where data already feeds business decisions and the return on investment has to be explained. Taking Level 4 as a first assessment target is rare in practice and not advisable — indicators need history before there is a trend, and a trend needs a mechanism before it means anything, and that order cannot be reversed.

How to organize the evidence

• Policy: indicator management rules, the measurement and review mechanism, threshold setting and deviation correction rules, and the appraisal rules for data management work. It must be visible who sets an indicator, how often it is reviewed, and what happens when it drifts — those three questions test whether the policy is executable.
• Process records: the indicator register, periodic measurement reports, deviation analysis and correction records, improvement tracking and re-measurement conclusions. A single period's report cannot show quantitative capability; only a trend and a before-and-after comparison can.
• Platforms and tools: indicator platforms, monitoring dashboards, quality rule engines, able to export historical trends and alert records. A tool supports the level only when it holds data, thresholds and trigger traces; a handsome cockpit screenshot does not.
• Data assets: the mapping from the indicator library to business definitions, historical results of quality measurement, and quantitative results split by domain, all consistent with the definitions in external reports. The same indicator must be the same number in policy, platform and report.

Common return reasons

• Outcome indicators only, no process indicators. The numbers look good, but which mechanism produced them cannot be said, so "steerable" cannot be shown.
• Numbers without a yardstick. No baseline, no target, no threshold, and quantification degrades into reporting figures; targets adjusted frequently with no change note fare even worse under questioning.
• Only one or two periods of data, so no trend can be drawn. Continuous measurement cannot be shown, and the "management" in quantitative management falls away.
• Definitions inconsistent in three places, or quantification covering only a few domains. The same indicator is three different numbers in policy, platform and report; and the remaining domains stay qualitative, so the level does not hold as a whole.

Level 5Optimizing: from "able to control" to "able to improve itself and give outward"

What is reviewed

Level 5 reviews whether the continuous improvement mechanism is mature: is there an organisation-level improvement path (proposal, pilot, evaluation, rollout); are there arrangements for knowledge management and for turning methods into assets; does data capability form a loop with business innovation — the business raises a new scenario, data capability supports it, and the result in turn drives capability upward; and are there checkable traces of outward output, such as published methods, external training, or participation in standards and specification work.

It also looks at whether improvement is reused. Something that stops inside the project it was done in, so that the next team starts over, is a project result, not an organisational capability. The judgement can be put in one sentence: has an improvement made last year become something another team can pick up and use this year. If yes, the loop holds; if not, optimisation is still at the level of individual points.

Who it fits

Companies whose data capability has become a competitive advantage and who provide data products or data services externally; organisations that carry industry method-building and take part in standards and specification work; and head-office units inside a group that are responsible for methodology output and enablement. The majority of enterprises should not set Level 5 as a target: the preparation effort is on another scale from Level 4, and the driver is usually not a tender — where the external requirement is only Level 3, spending the Level 4 to Level 5 budget on the business side produces a more direct return.

How to organize the evidence

• Policy: the continuous improvement mechanism, the rules for proposing and accepting innovation and improvement projects, knowledge management and the conversion of methods into assets, and the requirements for outward output (training, publishing methods, standards participation). It must be visible that improvement has an entry, a review and exit criteria.
• Process records: the improvement portfolio and retrospectives, records from pilot to rollout, knowledge base updates, evidence of external training and published methods, notes on external adoption or citation. The test is what the mechanism produces, not the occasional highlight.
• Platforms and tools: platforms supporting experimentation, model and algorithm governance and capability reuse, where the same capability is visibly called and iterated by several business lines; the value of the tool is that reuse becomes the default option.
• Data assets: the method asset library, reusable components and templates, a cross-business data product catalogue, and the records of their use and iteration. This is where the shape of the evidence differs visibly between Level 4 and Level 5.

Common return reasons

• Treating "we adopted new technology" as "we achieved optimisation". The material is a technology list and architecture diagrams, with no improvement mechanism, no effect verification and no rollout, so optimisation has nothing to rest on.
• Improvement as scattered projects. Each finishes and stops: no proposal standard, no retrospective, no reuse, and the next team starts again.
• Methods settle in people. The knowledge base is empty or has not been updated for a long time, and core methods live only in a few individuals' experience — when they move, it breaks.
• Outward output that is only publicity material, and a weak quantitative base. No training records, no publications, no note of adoption; or Level 5 is claimed before the Level 4 indicators and historical data even stand, so "continuous improvement" has no comparable starting point.

Evidence shared across levels: one base, thickened level by level

Spread the eight capability domains out, and a block of material turns up at every level. The difference is not whether it exists but how thick it is and how far back it can be traced. Building that block into one base and thickening it level by level saves far more effort than re-organizing it for each level, and it is easier to keep consistent.

The base is reusable because it answers the same set of questions at different depths. Thickening it can be understood as four layers:

Shared does not mean copied. There are three rules, and breaking any one of them shows up during the cross-check:

1. One version per data point. Organisation names, system names, post titles, data item names and dates must be identical across policy, catalogue, register and report. One character of difference costs time to explain; one date out of place can become a hard flaw.
2. The same policy must point to the depth this level cares about. One data quality rule is cited at Level 2 to prove "a rule exists", at Level 3 to prove "rules form a library and issues close", and at Level 4 to prove "measurement and thresholds are executable". Same clause, different thing to prove.
3. When upgrading, do not carry the previous level's narrative up wholesale. Level 3 material says "how many meetings we held"; Level 4 material has to say "which indicators those meetings moved". The same records can be used, but the angle of citation must change — leave the angle alone and the reader concludes you have not moved up.

The upgrade path: do not skip levels

The five levels are one continuous slope, not five labels to pick from at will. In practice a skipped level rarely holds, for a simple reason: the requirements of a higher level usually presuppose that the level below is already in place. Level 4 indicators mean something only when the Level 3 mechanism is running, and Level 5 improvement needs Level 4 measurement before there is a basis for comparison. Without the layer below, the layer above hangs in the air.

Where a skipped level breaks, in practice, comes down to four points, in fixed places:

So walk the path in this order, and do not reverse it:

• Coverage first, depth second. All eight capability domains need an answer; written lightly is acceptable, left entirely blank is not. Five domains blank and three written thickly is a shortage of coverage, not of depth.
• Let the mechanism run its periods first, then talk about scheduling. Records must cross months and even quarters before they show a mechanism in continuous operation rather than something assembled for the assessment. This step cannot be skipped and cannot be hurried.
• Indicators and baselines first, quantification second. With definition, calculation rule and baseline value all in place, measurement means something; without them it is a report under a different name.
• An improvement mechanism first, optimisation second. Improvement needs an entry, a review, a rollout and reuse; a few scattered projects are not the same as optimisation capability.

Four judgements are worth remembering:

• A level reflects the state of capability, not years in business. A company trading for ten years on thin mechanisms does not reach Level 3 by being old; conversely, a young company whose mechanisms run solidly may move faster than expected.
• Upgrading is not switching tracks. If one domain will not flow, moving to another domain does not solve the evidence problem; levels differ in depth, not in direction, and the material continues rather than restarts.
• Do not rebuild the material set for each upgrade. The base is the same one, thickened level by level; tearing it down each time consumes internal manpower, and internal manpower often affects progress more than the choice of body.
• Sustain the result once it is granted. A conclusion has a scope and a validity period, and if the mechanism stops and the records break, the next reassessment starts over and the earlier effort is wasted. Reassessment and maintenance requirements are subject to the issuing body's rules in force.

Action list: locate first, then add layers

Read all five levels and the work comes down to one line. Do not reverse the order — first locate the level you are really on, then find the gaps, then fix the mechanism, and only then talk about documents.

• ⬜Write your real present state in one sentence ("whoever hits it handles it", "a department has someone in charge", "it runs at organisation level", or "indicators are measuring it") — write what you can produce evidence for, not what you hope
• ⬜Find where the target level comes from: the tender document, the group appraisal rules or an internal requirement — what level the original text states, and by when
• ⬜Mark each of the eight capability domains: blank / policy but no records / records but no indicators / indicators but no trend — four bands are far more useful than "broadly compliant"
• ⬜Confirm one contact person per domain, not one person carrying all eight; a consultant cannot stand in at the interview stage
• ⬜Check continuity of records: pick one domain and see whether registers and minutes cover months or quarters; if everything sits in the last two months, run it longer first
• ⬜Check the depth of accountability: does the list stop at the department or reach post and person, and has the named person signed and do they know they were named
• ⬜Reconcile the data asset catalogue with the systems: pick three tables at random and see whether field meaning, source system and owner can be found
• ⬜If the aim is Level 4, write the indicator list and definitions first, then check whether baselines exist; an indicator without a baseline should run two periods before it is discussed
• ⬜If the aim is Level 5, go through the knowledge base and improvement register: how many of last year's improvements have been taken up by another team
• ⬜Before submitting, run one horizontal check: are names, system names, post titles and dates consistent across the eight files, and is any date out of order

By this point the five levels come down to one sentence at five depths: whatever you have genuinely done in data management, the material must be able to describe so that someone else can check it. A level is not chosen, it grows — policy grows process, process grows records, records grow indicators, indicators grow improvement. Any layer you try to skip will come back to find you on site.

On how to sequence DCMM against DSMM and ISO 27001, and which material can be shared, the assessment walkthrough goes further; for the data security specialism see DSMM in practice; for information security management systems see ISO 27001, ISO 20000 and CCRC information security service qualification; the overall map of management system certification is on the standards overview, the service scope is under certification services, process records from comparable projects are in cases, and the self-check tool is at quick lookup.

▍Not sure which level you are really on? Leave a comment noting "DCMM five levels" and I will send you an evidence comparison table split by level, so you can take stock yourself before deciding where to go.