DCMM Level 3 by Domain: What Each One Needs

Bottom line first: DCMM Level 3 is not "write one policy for every domain". Prepare on that idea and the documents pile up into a hill, and one question on site still brings the whole thing down. What Level 3 really means is that each of the eight capability domains can produce the trio of policy + execution + result — the policy says how it should be done, the execution records say it really was done that way, and the operating data says it produced an effect and is still going. Written but not done, Level 3 does not pass; done but not written, it also does not pass, because evidence you cannot produce is the same as work not done.

The test can be reduced to one sentence: take any single capability domain on its own, can you assemble within one hour the three things — who set the rule, how it has run over the past half year, and what it produced. If you cannot, that domain is still at Level 2. The typical Level 2 state is "someone is managing it" — a department has a policy and a named owner; the typical Level 3 state is "the organisation is managing it" — policies form a system, accountability lands on posts, cross-department processes work, and records span a continuous stretch of time.

This article takes the capability domains one by one. Every section uses the same four-part structure: what Level 3 looks for → the usual practice that stays at Level 2 → how to close the gap to Level 3 → evidence list. What is written here is a general framework; the specific clauses inside a domain, the judgement criteria and the sampling method are subject to the assessment body's rules for the current assessment period. This article does not deal with specific scores, weightings or clause numbers, and makes no commitment of any kind about the assessment outcome.

1. Data Strategy: from "leadership mentioned it" to a plan, a budget and annual actions

What Level 3 looks for

What is examined is whether the data strategy is written down, whether it is aligned with the business strategy, and whether it has been broken into annual actions. Three elements, none of them optional: a strategy or planning document that sets out the goals and the path; a set of annual plans with resource support (people, budget, tools); and a checking line that shows progress (who looked at execution, and when). Level 3 also expects to see how the data organisation and responsibilities are arranged — which line the data management function sits under, who is accountable for which kind of data, and whether data work has been brought into departmental appraisal.

The usual practice that stays at Level 2

The strategy lives in one line of meeting minutes — "we must take data seriously"; or there is a digital transformation plan, but it talks about system building throughout and not one sentence says how data is managed; the annual plan is a patchwork of project charters, listing "build a data middle platform" and "build master data", without saying who is responsible or what counts as done. Training is one briefing session, and even the sign-in sheet was not kept.

How to close the gap to Level 3

Rewrite the strategy from "vision" into "deliverable": goal → annual action → owning department → resource → checkpoint. There is a practical trick in the wording — after each goal add one sentence: "what is the concrete action this year". A goal that cannot be followed by that sentence should be deleted; keeping it only invites questions in the interview. The strategy document goes through internal approval and release, the annual plan is approved together with a budget, execution checks land in existing regular meetings (there is no need to set up a new meeting; hanging it on the quarterly business review is more sustainable), and training becomes a fixed activity with an audience, content, sign-in and feedback.

Evidence list

The judgement in this domain is blunt: what Data Strategy at Level 3 needs to see is a strategy that an annual plan can catch, not a polished planning text. If the strategy is written, the annual plan does not catch it and the budget cannot be found, the domain stays at Level 2. The specific judgement criteria are subject to the assessment body's rules for the current period.

2. Data Governance: the mechanism has to meet, decide and appraise

What Level 3 looks for

What is examined is whether governance runs as a real body: whether there is a layered data governance organisation (decision layer, management coordination layer, execution layer), how often each one meets, what it decides on, how resolutions are tracked; whether the policies form a framework (general charter + domain-specific methods + operating procedures) rather than a loose set of documents; whether data accountability lands on posts and people; whether cross-department data disputes have a clear adjudication path; and whether data work has entered appraisal.

The usual practice that stays at Level 2

One "Data Management Measures" and one part-time data administrator; cross-department matters depend on him asking people one by one. The governance committee exists only on paper, meets once a year, and the minutes say "agreed in principle". The accountability list says "the finance department is responsible for financial data" — ask the finance department who is responsible and nobody can answer. The appraisal form has no data item, or has one that has never deducted a point.

How to close the gap to Level 3

Four things in order: name the people, set the meetings, set the accountability, set the appraisal. Naming the people means putting the member list and duties of the three layers into appointment documents; setting the meetings means giving a fixed rhythm (for example, management deliberates quarterly and the execution layer coordinates monthly), and every meeting must have resolutions and a tracking table — minutes without a tracking table hardly count as evidence on site; setting the accountability means bringing the data accountability list to four complete columns — "data item — accountable post — accountable person — duty" — and getting the accountable person to sign (the signature step matters, and it also solves the frequent problem of "I did not know I had been made accountable"); setting the appraisal means putting one or two data indicators into departmental performance, with real scoring records behind them.

The policy system does not have to be written in full in one go; build the skeleton as "1 + N + M": one general charter covering organisation, responsibilities, process and appraisal; N domain methods corresponding to the key activities of the eight domains; M operating procedures and forms that land on concrete actions. Grow the flesh on a skeleton first — far better than eight documents that never cite each other.

Evidence list

Data Governance is the domain that gets asked about often and where gaps show easily, because it is inherently cross-department. One test: if a cross-department dispute about data can still only be settled by one person going round to coordinate, the domain is still at Level 2. The specific form of the adjudication mechanism is subject to the company's own governance policy, and whether it meets Level 3 is subject to the assessment body's rules for the current period.

3. Data Architecture: layered models and change records, not a single ER diagram

What Level 3 looks for

Four things are examined: the layered design of data models and the change records (conceptual, logical and physical layers each with outputs, model changes going through review with the version kept); data distribution and flow (which systems the data is produced in, where it flows, which one is the source system); management of integration and sharing (interface inventory, calling relationships, ownership); metadata management (collection and maintenance of technical and business metadata, with lineage or upstream/downstream relationships visible). It should also be possible to see how data architecture corresponds to business architecture and technical architecture — architecture is not a diagram IT draws for itself.

The usual practice that stays at Level 2

All you have is an ER diagram drawn years ago, and only part of one system at that; interface documents are scattered across project teams, and whoever calls an interface is the only one who knows it; metadata is a spreadsheet with table names and Chinese names, field-level information missing, and three months out of date; model changes rely on a developer saying "I added a field". The signature of this state: architecture information lives in people's heads, not in the system.

How to close the gap to Level 3

Start from three small things — low cost, quick effect: first set the naming and layering conventions (how tables, fields and codes are named, what each of the conceptual, logical and physical layers produces), then build an interface register (source system, target system, fields, frequency, owner, change method), then collect metadata automatically from the systems — manually registered metadata rarely survives three months, which is broad industry experience. Bring model changes into the existing requirement change process and leave one line on the review form — "impact on the data model" — which lands more easily than setting up a new process.

The data distribution diagram does not have to be pretty, but it must answer one question: for a key data item (customer, material, contract, for example), which systems hold it, which one is the source system, and how the rest are synchronised. If that cannot be answered, the architecture domain is not persuasive.

Evidence list

One-sentence test: Data Architecture at Level 3 needs to see the layered design of data models and the change records, not just one ER diagram; and it needs to see that the metadata is alive — point at a random table on site and the field meanings and origins can be queried. The specific focus of the architecture assessment is subject to the assessment body's rules for the current period.

4. Data Application: a scenario list, and value that can be traced back

What Level 3 looks for

What is examined is whether the data is really being put to use: whether there is a data application scenario list (scenario, user, data source, expected value, current status); whether analysis results enter business decisions (cited at decision meetings, adopted, reviewed afterwards); whether data services and open sharing have a catalogue and usage records; and whether application effects have ever been looked at again — going live is not the end.

The usual practice that stays at Level 2

There are plenty of reports, but nobody can say clearly which are in use and which nobody has ever opened. The business raises a requirement, IT builds a report, it is sent out, and whether it is used, whether it is accurate and whether it changed a decision — nobody follows up. Data analysis stops at "produce a monthly report"; the report is posted in a chat group and nobody replies. Open sharing is rarer still: either the data does not go out at all, or it goes out and nobody owns the definition.

How to close the gap to Level 3

The approach is to manage "application" as a process with a before, a middle and an after: before, a scenario list and priorities (which business pain point, which data, what effect is expected); middle, records of requirement, development and acceptance (who raised it, what the acceptance criteria are, who signed off); after, usage tracking and value review (access volume, citations, business-side feedback, and whether it led to a decision or a process changing).

The scenario list should be short rather than long, but it has to be true. Pick three to five scenarios whose business owners are willing to speak about the effect, and complete the process records — that is more persuasive than listing twenty scenarios nobody uses. Data services need a catalogue: who can apply, how they apply, who received it, how many times it was called — answer those four questions and open sharing holds up.

Evidence list

Test: Data Application at Level 3 looks at "what the data changed", not "how many reports were produced". The number of scenarios is not a capability; a scenario the business can speak about, and that can be traced to a decision or a process improvement, is one. The selection and judgement of scenarios are subject to the assessment body's rules for the current period.

5. Data Security: classification has to reach the field, and permissions and logs have to be checkable

What Level 3 looks for

Whether classification and grading land on specific data items (not a document of principles, but which tables and which fields belong to which level); whether access control runs by role and by approval (who can see it, who approved it, how often it is reviewed); whether audit logs are retained and searchable (access to, export of and changes to sensitive data are recorded); security policy, emergency plans and drills; and whether external sharing and entrusted processing carry assessment and contractual constraints.

The usual practice that stays at Level 2

There is an information security policy, and the classification table in its annex lists three tiers — "public / internal / confidential" — but it has never landed on specific system fields; permissions are granted by the DBA by hand, with no approval form afterwards; logs are switched on but kept for only a few days, so nothing can be found when a problem arises; the emergency drill is a paper plan that has never been run; data is handed over under a generic confidentiality agreement that says nothing about data purpose or destruction requirements.

How to close the gap to Level 3

Two main lines: land the classification on the assets, land the permissions on the process. The first is to tag key data items with a level and align them with the data asset catalogue — every data item in the catalogue shows its level, and once that is done the security domain is wired together with data architecture and data standards. The second is to turn permission granting from "finding a person" into "raising a ticket": application, approval, provisioning and periodic review, four steps, each with a trace; exports of sensitive data get a separate checkpoint.

Logs raise a practical problem: many companies have logs but do not use them. Level 3 does not look at whether logs are switched on, but at whether they can be searched and whether they have ever been searched — can a query be run on site by person, by table and by time period, and has a log review really been carried out in the past. Drills work the same way: run at least once a year, with a plan, a process, a conclusion and improvement items; a paper drill hardly counts on site.

Evidence list

One-sentence test: Data Security at Level 3 needs to show "what level this piece of data is, who can touch it, and whether it has been touched", and all three questions need answers before it counts as landed. If DSMM or ISO 27001 is being done at the same time, the classification, permission matrix and log groundwork can be shared, but the assessment criteria have to be aligned separately. The specific judgement in the security domain is subject to the assessment body's rules for the current period.

6. Data Quality: rules in a repository, issues closed in a loop, results someone reads

What Level 3 looks for

Four things: quality requirements come from the business (not a few rules IT made up on its own); rules form a repository (rule, validation logic, scope of application, threshold, owner); checking has a rhythm (run by cycle, with check reports, covering key data); issues close in a loop (discovery, assignment, correction, acceptance, review — none of them missing). It also examines whether quality results are used — whether there is a quality dashboard and whether it has been discussed at regular meetings.

The usual practice that stays at Level 2

The business says "the data is not accurate", IT investigates, finds it is an input problem, asks the business to fix it, the matter ends and nothing is recorded. The same problem appears again three months later and is investigated all over again. The signature is no rule repository, no ledger and no closed loop — quality work rests entirely on personal experience and breaks as soon as the person changes. Some companies buy a quality tool and configure a dozen rules, but cannot say who defined the rules or why the thresholds are set that way.

How to close the gap to Level 3

Five steps: choose the key data → define the rules → schedule the checks → build the ledger → take it into the regular meeting. Choosing data means choosing narrowly: cover three to five key data items that affect the business first (customer, material, contract, financial account and the like) and get the loop running — more useful than spreading across everything. Define the rules together with the business, with a concrete question — "what makes this data wrong" — because what the business can answer is a real rule.

The issue ledger is the core evidence of this domain. The format need not be complex, but it must have several columns: issue description, discovery date, scope of impact, owner, corrective action, completion date, acceptor. Once the ledger contains entries that span months and are closed, the domain basically holds up. The quality dashboard does not need to be flashy: saying clearly "how much was checked this period, how much was found, how much was closed" is enough.

Evidence list

Test: the mark of Data Quality at Level 3 is not "the data is clean" but "issues are found reliably and closed" — data can never be free of problems; what counts as capability is whether a cycle of discovery and correction forms. The specific requirements on the number of rules and the checking frequency are subject to the assessment body's rules for the current period and to the company's own policy.

7. Data Standards: definitions aligned enough to reconcile, standards landed in system fields

What Level 3 looks for

Whether the standards system covers the four object types: business terms, master data, indicator data and data elements (including codes). Whether standards have a complete drafting — review — release — adoption process; whether standards land in the systems (field naming, code tables and indicator calculation logic matching the standards); and whether standard changes are controlled (when a standard changes, do the downstream reports and interfaces follow).

The usual practice that stays at Level 2

There is a glossary of a few dozen terms, filed on the shared drive once it was finished. Indicator definitions are scattered across departmental report notes; the same "active customer" has three different calculations in the sales, finance and operations reports, and meetings start with half an hour of arguing about the definition. Master data is matched by hand, and the same supplier carries three codes in the system. The signature of this state: the standard is a document, not a constraint.

How to close the gap to Level 3

There is a pragmatic order: do indicator definitions first, then master data, then spread to data elements. The reason is that indicator definitions are where business disputes concentrate, and once that area is unified the willingness to cooperate across departments rises visibly; master data governance shows results directly (one object, one code) and wins business support easily; data elements and coding standards are more foundational and are better done later, carried forward by the mechanisms built in the first two steps.

Adoption is the watershed of this domain. Releasing a standard is not adoption: you have to be able to produce "the mapping between the field names in the standard and the field names in the system", and records that "a check against the standard was carried out before the new system went live". Every indicator needs a unified definition — definition, calculation formula, data scope, owning department — all four present before it can be reconciled.

Evidence list

Test: the hard indicator for Data Standards at Level 3 is "can it reconcile" — the same indicator reported by two departments gives the same number, and the origin of the definition can be explained. The number of standards means nothing; the proportion that has landed is what matters. The coverage of standards and the judgement criteria are subject to the assessment body's rules for the current period.

8. Data Lifecycle: from requirement to retirement, every stage needs an owner and a trace

What Level 3 looks for

Whether every stage of data — requirement, design and development, operation and maintenance, archiving, retirement — has management requirements and an owner. Three points matter: whether data requirements are brought into requirement management (rather than whoever shouts loudest going first); whether the design and development stage includes data design (model, definition, quality validation, security level); and whether archiving and destruction have approval and a ledger (this is the stage asked about often and often overlooked).

The usual practice that stays at Level 2

There is a process for systems going live and nobody manages them going down — an old system stops, the data stays in the database, and nobody can say who is responsible, how long it is kept or whether it may be destroyed. Archiving depends on operations habit, deleting data depends on DBA verbal confirmation with no approval form. Data requirements are mixed into business requirements, with no separate data impact assessment. The signature of this state: the first half (go-live) has a process, the second half (archiving, retirement) is blank.

How to close the gap to Level 3

What needs filling in is usually not the development process but the two things at the end: build an archiving list (which data, where stored, how long retained, who can retrieve it), and build a destruction and retirement process (application, approval, execution, record, plus a data disposal statement for retired systems). Once these two are written down and have run one round, the completeness of the lifecycle domain improves visibly.

At the front end, two low-cost insertions: first, add a column to the requirement template — "which data is involved, which downstream items are affected"; second, add one line to the design review — "whether the data model and the definitions have been aligned with the data standards". Two columns cost very little, yet they let the lifecycle domain, data standards and data architecture corroborate each other.

Evidence list

Test: Data Lifecycle at Level 3 looks at the closed loop — one piece of data from the requirement being raised to its destruction, with an owner and a record at every step. Doing only the first half, with the end left blank, still counts as Level 2 only. The specific retention requirements for archiving and destruction are subject to the company's own policy and to the rules of the competent party, and whether it meets Level 3 is subject to the assessment body's rules for the current period.

9. Three cross-domain evidence items: without them, all eight domains slip

After the eight domains have been filled in one by one, there is a further layer of common requirements. What really decides on site whether it "looks like Level 3" is often not how detailed one domain is written, but whether these three things hold across all eight domains.

The way to test these three is simple, and useful: pick any domain, take one policy requirement and follow it down three layers — is there a matching action in the system, a matching record in the ledger, and can the person named in the record explain why it is done that way. If the chain holds, the domain is at Level 3; whichever layer breaks is the layer to fix. There are usually only three reasons it breaks: the policy was borrowed, the system was not configured, or no record was kept.

One point that is easily overlooked: cross-domain consistency. The classification and grading of data security has to match the data asset catalogue, the indicator definitions of data standards have to match the quality rules, and the accountability list of data governance has to match the permission reviewers in the security domain. Eight sets of material, each complete on its own and contradicting each other, will still be questioned on site. When collecting material, build a "domain — material — owner" cross-reference table first, then check the names of people, systems and posts and the dates across the board. The specific verification method and the sampling criteria are subject to the assessment body's rules for the current period.

10. Action checklist: follow this order and halve the rework

Twelve lines, in order. Move on only when every line has a concrete answer; the one you cannot answer is this week's to-do.

• ☐ I am clear whether Level 3 is a target or a process — what the level requirement in the tender or appraisal document actually says
• ☐ Each of the eight capability domains has its own contact, rather than one person carrying eight
• ☐ For every domain I can state what the policy, execution and result trio is, not just the name of a document
• ☐ We have run a domain-by-domain gap review that produced specific items, not "largely conformant"
• ☐ The policy system has the general charter + domain methods + operating forms layers, and they cite each other
• ☐ The data accountability list reaches the post and the person, with signatures, and the people named know they are named
• ☐ The tables and fields in the data asset catalogue can be checked one by one in the systems
• ☐ Key records span months or even quarters continuously, and were not filled in all at once
• ☐ Quality, security and standards each have their own closed-loop evidence (issue ledger, permission review, adoption check)
• ☐ Archiving and destruction in the lifecycle domain have a ledger and approvals, and are not a blank section
• ☐ The names of people, systems and posts across the eight domains have been cross-checked, with no contradictions
• ☐ I have prepared people who can be interviewed: the governance lead, the contact for each domain, and a senior manager who can explain the investment

If fewer than six can be ticked, now is not the right time to book an assessment — getting the trio running first saves far more effort than booking the on-site days and filling in evidence afterwards. If only governance, security and quality have been filled in out of the eight, and the other five are blank, what is missing is coverage rather than depth, and that has to be dealt with at the review stage.

Conclusion: Level 3 tests whether it runs, not how well it reads

Spread the eight domains out and the requirements turn out to be highly consistent: written rules, processes that really run, records kept and searchable, and people who can explain them. The domains differ only in their object — Data Strategy is about goals and resources, Data Governance about organisation and policy, Data Architecture about models and metadata, Data Application about scenarios and value, Data Security about levels and permissions, Data Quality about rules and closure, Data Standards about definitions and landing, Data Lifecycle about stages and the end of the chain.

So the recommended order of preparation is: review the trio domain by domain → fill in the policy skeleton → embed the actions into systems or process checkpoints → let the mechanism run long enough for the records to grow naturally → then discuss the assessment schedule. The reverse — writing eight policies first and then hunting for records to match them — is a frequent starting point for rework, because the policy states "what should be" while the records reflect "what is", and the gap between the two has to be closed sooner or later.

Further reading: for the overall DCMM flow and the rework points, see the full DCMM assessment process; for concepts and level definitions, see the DCMM knowledge base page; for the data security specialism, see DSMM in practice and the DSMM knowledge base page; for information security management systems, see ISO 27001, ISO 20000 and the CCRC information security service qualification; the overall map of management system certification is on the management systems overview, our service scope is under services, process records from comparable projects can be found in cases, and the self-check tool is at quick lookup.

▌Which of the eight domains still has only policies and no records? Leave a comment or message me with "DCMM Level 3 by domain" and I will send you an evidence cross-reference table split by domain, so you can review it yourself before deciding whether to start.