Ask an ITSM manager how mature their service management is, and you’ll usually get a confident answer within seconds — “we’re pretty solid,” “we’re still pretty early,” “somewhere in the middle.” Ask them to back that up with anything more specific than a feeling, and the confidence tends to evaporate. That gap between how mature a team believes it is and what it can actually demonstrate is exactly what an ITSM maturity assessment is built to close.
This isn’t a new idea — maturity models have existed in software and process engineering since CMM in the late 1980s — but it’s a widely misunderstood one. Most teams either skip it entirely (too busy running tickets to measure how well they’re running tickets) or run something so shallow it just confirms whatever they already believed. Done properly, a maturity assessment is one of the highest-leverage things an ITSM program can do before asking for a budget, a platform migration, or a headcount increase — because it turns “I think we need more automation” into “we’re at Level 2 on tooling and Level 4 on process, and that gap is specifically where our SLA breaches are coming from.”
What a maturity assessment actually measures
A proper ITSM maturity assessment scores an organization across several independent dimensions — not one overall grade. The dimensions that matter most consistently across frameworks are:
- Process — are your ITSM processes (incident, problem, change, request) formally defined, followed consistently, and improved on a cadence, or do they exist mostly as tribal knowledge?
- Tooling & automation — does your platform enforce and support the process, or does the process route around what the tool can’t do?
- Data quality — can you trust the CMDB, the ticket categorization, the reporting? Immature data quietly undermines every other dimension.
- Governance — is there real ownership, defined KPIs, and a review cadence, or does improvement only happen when something breaks badly enough to force it?
- Culture & adoption — do people actually use the process and tool as designed, or maintain a shadow workaround because the official path is too slow or too rigid?
Scoring these separately matters because they rarely move together. We’ve assessed organizations with genuinely well-designed incident processes running on a platform nobody configured past its defaults — and the reverse, expensive best-in-class tooling running processes barely more disciplined than a shared inbox. A single “how mature are we” number hides exactly the information you need to know where to invest next.
The major frameworks, compared
You don’t have to build a scoring methodology from scratch — several established frameworks already exist, and picking the right one (or blending two) depends on what you’re trying to prove and to whom.
| Framework | Best for | Trade-off |
|---|---|---|
| CMMI for Services (CMMI-SVC) | Organizations that need a formally certifiable, audit-defensible maturity rating — common in regulated or government-adjacent environments | Heavyweight; a full appraisal is a significant time and cost commitment |
| Axelos / PeopleCert ITIL Maturity Model | Teams already operating in ITIL practice terms who want a self-assessment mapped directly to ITIL’s own language | Self-reported unless paired with independent facilitation, which can inflate scores |
| Gartner ITScore for ITSM | CIOs benchmarking against industry peers, using an analyst-backed scale in board conversations | Requires a Gartner subscription; less prescriptive on the “how to improve” side |
| ISO/IEC 20000 self-assessment | Organizations pursuing or maintaining formal ISO 20000 certification | Oriented toward certification compliance rather than operational improvement per se |
| A practitioner-built 5-level model (what we use below) | Teams that want something fast, practical, and directly actionable without a licensing or certification overhead | Not independently certifiable — it’s a diagnostic tool, not a credential |
A practical 5-level model
For day-to-day diagnostic use — the kind that feeds directly into a roadmap rather than a compliance file — we use a five-level model applied across the dimensions above. It’s deliberately compatible with the CMDB-specific and asset-management-specific maturity models we’ve published before, so an organization can run the same scale across every part of its operation and get a single, comparable picture.
| Level | Name | What it looks like |
|---|---|---|
| 1 | Ad Hoc | Reactive, person-dependent. No documented process; the tool is used as a ticket log, not a workflow engine. |
| 2 | Repeatable | Process exists informally and is followed inconsistently. Some automation, applied unevenly. |
| 3 | Defined | Process is documented, trained, and generally followed. Tooling enforces most of the workflow. |
| 4 | Managed | Process is measured against KPIs with a regular review cadence. Data is trustworthy enough to drive decisions. |
| 5 | Optimized | Continual improvement is systematic, not reactive. Automation extends to proactive and predictive work, not just execution. |
How to actually run one
1. Scope the dimensions
Decide upfront which dimensions and which service areas are in scope. Assessing everything at once for a large organization usually produces a shallow result; narrowing to incident, change, and CMDB first, for example, produces something you can actually act on within a quarter.
2. Interview and gather evidence
This is the step that separates a real assessment from a survey. Interview people who actually do the work, not just the process owners who wrote the documentation — and pull real data (ticket volumes, SLA breach rates, reopen rates, backlog age) rather than relying on self-reported scores alone. A process owner’s confidence and a technician’s daily reality frequently disagree.
3. Score against the model
Score each dimension independently against defined criteria, not against a gut feeling of “we’re doing okay.” Written criteria per level — like the table above — keep the scoring defensible and repeatable, so the same assessment run a year later is actually comparable.
4. Benchmark
A score in isolation doesn’t tell you much. Compare it against either your own target state (where the business needs you to be) or, where available, industry peer data. This is where frameworks like Gartner’s ITScore add value that a purely internal scorecard can’t.
5. Build the roadmap
The output of an assessment should never just be a set of numbers — it should be a prioritized list of what moves the needle fastest. In our experience, the biggest quick win is almost never the dimension that looks worst on paper; it’s the dimension whose weakness is quietly capping every other score, which data quality frequently turns out to be.
Common pitfalls
- Measuring the tool and calling it the process. A platform’s feature list is not evidence of process maturity — see our piece on process maturity vs. tool maturity for why these need to be scored separately.
- Treating it as a one-time event. A maturity assessment run once and filed away has a shelf life of about a year before the organization has drifted past it. Reassessing on a fixed cadence — annually at minimum — is what turns it into a management tool instead of a snapshot.
- No executive sponsor. Without someone senior accountable for acting on the results, an assessment becomes a well-documented list of problems nobody has the authority to fix.
- Self-scoring without evidence. Teams that grade their own homework tend to average a full level more optimistic than an independently facilitated assessment finds. If the assessment is meant to justify a budget ask, an outside perspective carries more weight anyway.
A simple scorecard to start with
Before commissioning a full assessment, most teams get real value from a rough self-score. For each dimension, honestly rate your organization 1 through 5 against the level descriptions in the table above, and be specific about the evidence behind each score — not the aspiration. If you can’t point to a KPI, a report, or a specific example supporting a “4,” it’s probably a “3.” The dimension with the lowest score relative to where the business needs it is almost always where the next investment should go — and that’s usually a more useful starting conversation than “should we upgrade the platform.”
Frequently asked questions
How long does an ITSM maturity assessment take?
A focused assessment covering two or three process areas typically takes two to four weeks, including interviews, data pulls, and roadmap development. Organization-wide assessments across every ITSM discipline can run six to eight weeks.
Do we need a consultant, or can we run this internally?
You can run a useful first pass internally using the scorecard approach above. The value of an external or independently facilitated assessment is mainly in removing self-scoring bias and adding peer benchmarking data your internal team doesn’t have access to.
What’s the difference between a maturity assessment and a tool assessment?
A tool assessment evaluates whether your platform is configured and licensed correctly for what you need. A maturity assessment is broader — it includes tooling as one of several dimensions alongside process, data, governance, and culture. See our ITSM Tool Assessment if tooling specifically is your immediate concern.
If you’d rather have this run by people who do it every week instead of building the scorecard from scratch, our ITSM Tool Assessment service and the related CMDB Maturity Model and process vs. tool maturity guides are good next stops — or get in touch and we’ll help you scope one.
&media=https://desqcon.com/wp-content/uploads/2026/09/thumb-maturity.webp){kind=link}