Data maturity assessment questions: 22 questions with an answer for every level

A data maturity assessment questionnaire is a set of questions that places each area of an organization’s data management on a maturity level, from Initial to Optimized, based on what people can see happening today. A good one gives you a score you can defend to an executive and a short list of where to start. Below are 22 questions we wrote for this post, two for each of the 11 DAMA-DMBOK knowledge areas. Each has five answers that describe what you would see at each level, and each area ends with the evidence that settles an argument.

Key takeaways

• Ask two questions per knowledge area for a baseline: 22 questions cover all 11 areas of the DAMA Wheel.
• Write every answer as an observable state, one per level, so people choose what they see rather than how much they agree. Saris, Revilla, Krosnick and Shaeffer (Survey Research Methods, 2010) found agree/disagree scales gave much lower-quality answers than questions with item-specific options.
• Offer “Don’t know” and leave it out of the score. A guess pulls the average toward the middle and hides the gap you most need to see.
• Score each area as the average of its answers, then map it to a level: below 1.5 is level 1, below 2.5 level 2, below 3.5 level 3, below 4.5 level 4, and 4.5 or above level 5.

Updated November 2026.

How to use these questions

Copy the questions into a spreadsheet with one row per question and one column per person. Send it to five to ten people who see data management from different sides. A finance data owner, the person who runs reporting, an IT lead, an analyst and someone from compliance make a good starting group. Ask each person to answer alone, for the organization as it is this quarter, not as the strategy says it will be.

For every question, the five answers run from level 1 (Initial) to level 5 (Optimized), in order. Pick the highest one that is fully true. If the honest answer is “level 3 in one division and level 1 everywhere else”, choose 1 or 2 and write a note. Every question also has a sixth option, “Don’t know”.

The areas follow the DAMA Wheel. The questions and answers are our own wording, written for this post. DAMA and DAMA-DMBOK are trademarks of DAMA International, and Level Up Your Data is not affiliated with or endorsed by DAMA International.

Why each answer describes a state, not an opinion

A typical template asks people to rate a statement from 1 (strongly disagree) to 5 (strongly agree): “We have effective data governance.” Two people can look at the same governance forum and answer 2 and 4. One is thinking about the forum, the other about the policies it hasn’t written yet. Agreement scales also pull answers toward yes. Survey researchers call that acquiescence, and Saris and colleagues’ 2010 study found that questions with item-specific answer options produced much better-quality responses than agree/disagree versions of the same questions.

A state answer removes the guesswork. “Named business owners for critical data, written in a register” is either true or it isn’t, and anyone can check it. It also tells the reader what the next level looks like, which turns a score into a plan.

The data maturity assessment questionnaire: 22 questions by knowledge area

Data governance

1. Who decides what a critical data item means, and who may change it? Think of the figures in your main board report.

1. Nobody has that job; whoever builds the report decides.
2. A few data sets have an informal owner, usually in IT.
3. Named business owners for critical data, written in a register.
4. Owners make decisions in a regular forum, and decisions are recorded and followed up.
5. Ownership is reviewed every year, and owners’ decisions are tracked against business outcomes.

2. How are data policies written and followed? Count only policies staff could find today.

1. There are no written data policies.
2. Policies exist but are out of date or hard to find.
3. Current policies, approved by a governance forum, are published where staff look.
4. Compliance is checked and breaches are reported to the forum.
5. Policies are revised at least yearly from compliance results and incidents.

Ask for the ownership register and the minutes of the last two governance meetings. Minutes with decisions and actions point to level 3 or above; terms of reference with no minutes usually mean level 2. Our data governance maturity model has a fuller rubric if governance is your focus.

Data architecture

3. Is there a description of the current and target data architecture that projects actually use? A slide from a strategy day doesn’t count unless projects refer to it.

1. None exists; each project designs its own.
2. Diagrams exist for some systems, drawn for past projects.
3. Current and target architecture are documented and kept up to date by a named team.
4. Projects are reviewed against the target before they are approved.
5. The target is updated from business strategy and review findings, and drift from it is measured.

4. Are architecture standards, such as which system is the source for each subject, written down and enforced? Answer for the last year of projects.

1. There are no standards.
2. A few architects know the standards, but they aren’t written down.
3. Written standards name the authoritative source for each major subject area.
4. Exceptions need approval and are tracked to closure.
5. Exceptions are counted and reported, and the trend is used to change the standards.

Pick the last two projects that went live and ask whether either was reviewed against the target architecture. A yes with a written record of the review is level 4 evidence.

Data modeling and design

5. On a new system or data set, how are the data requirements modeled? Consider the last three builds.

1. Tables are built straight from the screens or the source files.
2. Some projects produce models, with no common standard.
3. Conceptual, logical and physical models are produced to a modeling standard.
4. Models are peer reviewed and reuse shared enterprise entities.
5. Models stay in step with what is deployed, checked automatically.

6. Can you find a current data model for your most important system? Current means it matches production.

1. No model exists.
2. One exists, but nobody trusts it to match production.
3. A current model sits in a shared repository with an owner.
4. Changes to production go through the model first.
5. Model and production are compared automatically, and differences are fixed within an agreed time.

Open the model for one critical system and compare five tables with production. If they differ, the honest answer to question 6 is level 2, whatever the modeling standard says.

Data storage and operations

7. When was a backup of a critical system last restored in a test, and did it work? A restore after a real outage counts only if it was planned for.

1. Restores have never been tested.
2. Restores happen only after something fails.
3. Recovery is tested on a schedule for critical systems, and the results are recorded.
4. Recovery time and recovery point targets are met in tests and reported to the business.
5. Test failures lead to changes in the recovery design, and targets are reviewed with system owners each year.

8. What happens to data once it is no longer needed? Think of transactional systems as well as the data warehouse.

1. Data is kept forever, or deleted when space runs out.
2. Some systems have retention settings, chosen by the technical team.
3. Retention periods are set by class of data and approved by the business and legal.
4. Retention and deletion run automatically and are checked.
5. Rules are reviewed after legal or business change, and storage cost is tracked against them.

The last recovery test report for a critical system settles question 7. No report means level 1 or 2, however confident the team sounds.

Data security

9. Is data classified by sensitivity, and does the classification decide who gets access? Answer for systems that hold personal or commercially sensitive data.

1. Data is not classified.
2. A classification scheme exists on paper but isn’t applied.
3. Critical systems and data sets are classified, and access rules follow the class.
4. Access is granted by role and reviewed on a schedule, with removals recorded.
5. Classification and access are checked automatically, and exceptions alert the data owner.

10. What happens when someone proposes a new use of personal data? Think of the last analytics or AI project that used customer data.

1. Privacy comes up only after a complaint or a breach.
2. The privacy officer is consulted informally on large projects.
3. A privacy impact assessment is required for every new use of personal data.
4. Assessments are tracked, their actions followed up and completion reported.
5. Findings from assessments shape design standards, and the process is audited each year.

Request the most recent access review for a system holding personal data. A dated review with removals carried out supports level 4.

Data integration and interoperability

11. How does data move between your main systems? Include the spreadsheets people email each month.

1. Mostly manual exports and emailed spreadsheets.
2. Point-to-point interfaces, built one at a time and each different.
3. Teams reuse shared integration patterns and tools, with documentation.
4. Pipelines are monitored, and failures alert an owner and are fixed against a target time.
5. Integration is planned from the target architecture, and point-to-point links are retired each year.

12. When a feed fails or arrives late, how soon does someone know? Use the last failure you remember.

1. When a user spots wrong numbers.
2. When someone on the technical team checks the logs.
3. Automated alerts go to a named support team.
4. Alerts state the business impact, and incidents are tracked to a root cause.
5. Failure trends are reviewed, and the worst feeds are redesigned.

Ask who holds the list of interfaces between systems. If nobody can produce one, question 11 is level 2 at best.

Document and content management

13. Can staff find the current version of a policy, contract or record when they need it? Answer for someone outside the team that wrote it.

1. Documents sit in personal drives and inboxes.
2. Shared drives exist, organized differently by each team.
3. Key document types live in a managed repository with a common structure, metadata and version control.
4. Search works across repositories, and duplicates are monitored.
5. The structure is improved from search and usage data.

14. Are records kept and disposed of according to a schedule? Email and chat count as records where the law says so.

1. No retention schedule exists for documents.
2. A schedule exists, but few teams apply it.
3. Records are classified against an approved schedule.
4. Disposal is carried out and recorded, and legal holds are managed.
5. The schedule is audited, and updated after legal or business change.

A quick test: ask someone outside the records team to find last year’s version of a named policy, and time it.

Reference and master data

15. How many versions of the same customer, product or supplier exist across your systems? Pick the domain that matters most to you.

1. Nobody knows.
2. Duplicates are known, and teams reconcile them by hand for reports.
3. One system is designated as the source for each master domain, with written match rules.
4. Matching and merging run automatically, and duplicate rates are measured.
5. Master data quality targets are set with domain owners and met.

16. How are shared code lists, such as countries, product categories or status codes, managed? Choose one list that several systems use.

1. Each system keeps its own list.
2. Lists are copied between systems and drift apart.
3. One maintained list per code set, with an owner, feeds the systems.
4. Changes are approved and versioned, then sent to every system automatically.
5. Code sets are mapped to external standards where they exist and reviewed on a schedule.

Pick one customer and search for them in three systems. The number of records you find is a better answer than any policy document.

Data warehousing and business intelligence

17. When two reports show different numbers for the same measure, what happens? Revenue and headcount are the usual suspects.

1. People argue, then use the number their manager prefers.
2. An analyst investigates each time, from scratch.
3. Certified data sets and a defined measure are the agreed source.
4. A governed semantic layer holds the measure definitions, and certified reports are labeled.
5. Report use and trust are measured, and uncertified duplicates are retired.

18. Do leaders use the reports to make decisions? Look at the main management meetings, not the analytics team.

1. Leaders rely on spreadsheets prepared for each meeting.
2. Reports exist, but key decisions still run on manual extracts.
3. Standard reports are used in the main management meetings.
4. Self-service on governed data is available, with training and support.
5. Decisions cite the reports, and reports nobody opens are retired.

Look at the pack from the last executive meeting. If its numbers came from a spreadsheet someone built that week, question 18 scores no higher than 2.

Metadata management

19. Can someone new find what a field or measure means without asking a colleague? Try it with a recent hire.

1. Definitions live in people’s heads.
2. Some definitions are written in project documents and spreadsheets.
3. A business glossary covers the critical terms, each with an owner.
4. A searchable catalog links glossary terms to the data sets and reports that use them.
5. Glossary and catalog use is measured, and gaps are filled from what people search for.

20. For your most important report, can you trace each number back to its source? Choose the report the board or the regulator sees.

1. No, and nobody has tried.
2. Only by asking the person who built it.
3. Lineage is documented for critical reports.
4. Lineage is captured automatically for critical data and kept current.
5. Lineage is used to assess the impact of every change before it is made.

Pick one figure from the board report and ask for its definition and source system. An answer in five minutes suggests level 3 or 4. A week of emails suggests 1 or 2.

Data quality

21. Are data quality rules defined and measured for critical data? Critical data is the data your key reports and processes depend on.

1. Quality is judged when someone complains.
2. Some checks exist, run by individual teams.
3. Rules for critical data elements are defined by dimension, with thresholds.
4. Rules run automatically, and results reach data owners on a dashboard.
5. Quality targets are part of owners’ objectives, and thresholds are raised over time.

22. What happens after a data quality issue is found? Follow the last issue you know about.

1. The figure is corrected in the report, and the source stays wrong.
2. The issue is fixed at the source, case by case.
3. Issues are logged, given an owner and tracked to closure.
4. Root causes are found and fixed, and recurrence is measured.
5. Issue trends drive process and system changes before new issues appear.

Ask for the issue log and count how many closed issues name a root cause. The six data quality dimensions are a good way to write the rules in question 21.

How do you score the answers?

We score this kind of questionnaire the same way every time. Each answer is worth its level, from 1 to 5. “Don’t know” is left out. A person’s score for an area is the average of their answers in it. The team’s score is the average of the people who answered, and the overall score is the average of the areas.

For illustration, three people answer the two Metadata Management questions. Ana picks 2 and 2, so her area score is 2.0. Ben picks 3 for question 19 and 2 for question 20, which gives 2.5. Chloe answers “Don’t know” for question 19 and 1 for question 20, so her score is 1.0, from the one question she could answer. The team’s Metadata score is (2.0 + 2.5 + 1.0) ÷ 3 = 1.8, which is level 2 (Developing).

Look at the spread as well as the average. Ben and Chloe are a level and a half apart, which usually means they look at different parts of the organization. That gap is the most useful conversation you will have in the debrief, and our post on running a data maturity survey with a team covers how to read it. If Chloe had guessed 3 instead of answering “Don’t know”, the team score would have risen to 2.2 and the gap would have been hidden. The data maturity model post explains what each level looks like in practice.

When to go deeper than two questions per area

Two questions per area is a baseline, enough to find the two or three weakest areas. Go deeper, with six or more questions in an area, in three cases: you are about to fund work there, people’s answers differ by more than a level, or an auditor will read the result. The data maturity assessment guide covers the full method, from choosing who answers to turning the scores into a 90-day plan.

If your organization runs data management as a funded program under regulatory scrutiny, questions organized by capability may suit you better than knowledge areas. The DCAM framework is built that way, and DAMA-DMBOK vs DCAM compares the two.

Frequently asked questions

What questions are asked in a data maturity assessment?

A data maturity assessment asks how each area of data management works today. Typical questions cover who owns data, how quality is measured, whether definitions and lineage exist, and how data is secured and reported. Good questions describe an observable situation for each maturity level, so people answer from what they see.

How many questions should a maturity assessment have?

Two questions per area is enough for a baseline: 22 for the 11 DAMA-DMBOK knowledge areas. A detailed questionnaire might ask six per area, 66 in all. That takes closer to 45 minutes and works best answered with the team, so keep it for the areas you plan to act on.

Should a maturity questionnaire use a 1 to 5 scale?

Score on 1 to 5, but don’t ask people to rate agreement on 1 to 5. Give five written answers, one per level, that describe what you would see, and let the level be the score. People then answer from facts, and research on survey design (Saris and colleagues, 2010) found item-specific answers give better-quality data than agree/disagree scales.

How do you handle “don’t know” answers?

Offer “Don’t know” on every question and leave it out of the score. Counting it as a 1 punishes honesty, and a forced guess drags results toward the middle. A high share of “Don’t know” in an area is a finding in itself: nobody can see how that area works.

Summary

Ask two questions per knowledge area, write every answer as a state someone could check, and keep “Don’t know” out of the score. Send the 22 questions to five people from different parts of the organization this week, and start with the two areas where their answers are lowest or furthest apart.

Template