Updated September 2026.
Most IT leaders can tell you, in a sentence, roughly how mature their service management is. Fewer can tell you why they believe that, or what would need to change for the number to go up. A maturity model exists to close that specific gap, not by handing you a grade, but by giving you a shared, repeatable way to describe where a process stands today and what the next step up actually looks like.
This post is about the model itself: where the idea came from, what an ITSM maturity model is actually made of, and, the part most explanations skip, what an organization gets out of using one beyond a nicer chart for a steering committee deck. If you’re looking for a step-by-step guide to running an assessment, see What Is an ITSM Maturity Assessment? A Practical Framework (+ Scorecard). This piece is the layer underneath that: the model that the assessment measures against.
Quick Answer: What Is an ITSM Maturity Model?
An ITSM maturity model is a structured scale, typically five levels, from ad hoc to optimized, used to describe how consistently, how measurably, and how effectively an IT service management process is run. It helps organizations replace subjective impressions (“we’re doing okay”) with a specific, evidence-based description of current capability, and it gives every level after the first one a concrete definition of what improvement looks like. Maturity models don’t rate people or judge effort; they describe process capability, which is a narrower and far more useful thing to measure.
What Is a Maturity Model, Really?
The idea didn’t start in IT. In 1979, quality management consultant Philip Crosby published a “quality management maturity grid” in his book Quality Is Free, describing five stages an organization moves through as it gets better at managing quality, from not really understanding the problem to treating quality improvement as a normal, permanent part of how the business runs. That basic shape, a small number of stages, each one building on the last, each one observable rather than aspirational, turned out to be useful far outside manufacturing.
In the late 1980s, the Software Engineering Institute at Carnegie Mellon University, working under Watts Humphrey, adapted that idea into the Capability Maturity Model (CMM) for software development, formally published in 1991. CMM gave software organizations a five-level scale to describe how repeatable and well-managed their development process was, independent of which methodology or tools they happened to use. It was later broadened and superseded by CMMI (Capability Maturity Model Integration), which is still maintained today and is the direct ancestor of the level definitions used across most modern maturity models, including the ones built specifically for ITSM.
Strip away the industry-specific vocabulary, and a maturity model is really just three things bolted together:
- A defined set of levels, usually four or five, where each level describes a distinct, recognizable state, not just “better than the last one.”
- A defined set of dimensions, the areas being assessed, such as process, people, or tooling, so the model measures more than one thing at once.
- Observable criteria at each intersection of level and dimension, so two different assessors looking at the same evidence land on roughly the same score.
That third point is what separates a real maturity model from a vibe. If the criteria aren’t observable, if “mature” just means “the team that built the model liked how you do things”, it isn’t a maturity model. It’s an opinion with a scorecard glued to it.
Why ITSM Needed Its Own Maturity Model
CMMI was built for software engineering: requirements, design, build, test, release. IT service management is a different discipline. It’s about running services after they exist, not building them. Incident response, change approval, problem management, service requests: these are operational and process-heavy in a way that generic software maturity models don’t describe well.
ITIL itself has evolved its own thinking on this. ITIL v3 (2011) introduced Continual Service Improvement as one of its five core publications, which leaned heavily on maturity assessment as the starting point for improvement work. ITIL 4 folded that into the broader “continual improvement” practice and the ITIL 4 Maturity Model, which several training and consulting organizations, including Beyond20, have published detailed guidance on. The common thread across all of these: process maturity assessment isn’t a side activity in ITSM. It’s one of the standard inputs to deciding what to fix first.
What most organization-specific or consultant-built ITSM maturity models have done since is take the CMMI-style five-level scale and re-anchor the criteria at each level to service management specifics, incident and problem workflows, change advisory boards, CMDB accuracy, service desk staffing, instead of software build pipelines. The scale is inherited; the content at each level is ITSM’s own.
The Anatomy of an ITSM Maturity Model: Levels × Dimensions
Every credible ITSM maturity model is really a small grid: levels down one side, dimensions across the top. The five-level scale below is the version used throughout DesQcon’s own maturity content and assessments, and it lines up closely with both the CMMI levels and the ITIL 4 Maturity Model’s stages.
| Level | Name | What It Looks Like |
|---|---|---|
| 1 | Ad Hoc | Work happens, but inconsistently. No agreed process, no documented roles, outcomes depend heavily on who’s on shift. |
| 2 | Developing / Repeatable | Basic structure exists, a tool, a rotation, a rough process, but it’s applied unevenly and rarely reviewed. |
| 3 | Defined | The process is documented, agreed, and consistently applied. Roles, inputs, outputs, and escalation paths are clear no matter who’s on duty. |
| 4 | Managed | The process is measured. KPIs are tracked on a regular cadence and used to catch drift before it becomes a problem. |
| 5 | Optimized | The process improves continually based on evidence. Automation removes manual toil, and improvement is a habit, not a project. |
The dimensions are where models tend to diverge more from each other, because different organizations care about different slices of capability. DesQcon’s framework, for example, scores six dimensions rather than folding everything into one axis, People, Process, Tool, Automation, AI, and Governance, because a single blended score hides exactly the information that makes a maturity model useful in the first place. A team can have a well-documented, Level 4 process running on a Level 2 tool with no integration to monitoring; a single average would report that as “Level 3, fine,” and nobody would know where to spend the next budget cycle. The full breakdown of what each of the six dimensions measures, and how questions map to levels, is covered in the ITSM Maturity Assessment Methodology page.
The two-axis structure, level times dimension, is the part that makes a maturity model an actual diagnostic tool instead of a label. A single “we’re a 3 out of 5” doesn’t tell an operations director anything they can act on Monday morning. “You’re a 4 on Process, a 3 on Tool, and a 2 on Automation” does.
How an ITSM Maturity Model Helps Organizations
This is the part that gets glossed over in most explanations, which tend to stop at “it tells you how mature you are” and move on. The actual value shows up well before and well after the score itself.
1. It replaces guesswork with evidence
Ask five people on the same team to rate the team’s incident management maturity, and you’ll usually get five different answers, often for five different reasons, one person is thinking about tooling, another about the last bad outage, another about morale. A maturity model forces everyone to score against the same defined criteria, so the resulting number reflects the process, not whoever happened to be asked.
2. It tells you where to spend money next, not just that you should
Budget conversations about ITSM tend to default to “we need a better tool” because tools are visible and easy to point at. A maturity assessment that separates Process from Tool from Automation from People routinely surfaces the opposite conclusion, that the existing tool is underused, and the real gap is training, or an unenforced escalation policy, or a CMDB nobody trusts. Spending on the wrong dimension is one of the most common and most avoidable forms of ITSM budget waste, and a dimension-level maturity score is the cheapest way to avoid it.
3. It creates a shared vocabulary across teams that don’t naturally agree
“Mature” means something different to a service desk lead, a CAB chair, and a CIO. A defined five-level scale with observable criteria at each level gives all three the same reference points, which matters most in exactly the conversations where it’s usually missing, budget requests, vendor comparisons, and post-incident reviews where blame and process gaps get tangled together.
4. It makes improvement measurable over time
Without a baseline, “we improved” is a feeling. With a maturity score taken at two points in time. It’s a number, Process moved from 2.4 to 3.1, Automation didn’t move at all. That’s the difference between a improvement initiative that can defend its own budget renewal and one that can’t.
5. It de-risks big decisions before they’re made
Platform migrations, outsourcing decisions, and new AI tooling all assume a certain baseline of process maturity to succeed. An organization with Level 2 process discipline that automates a Level 2 process doesn’t get a Level 4 outcome, it gets the same inconsistency, faster. Knowing the starting maturity level before committing budget to automation or a platform change is one of the more common ways a maturity assessment prevents an expensive mistake rather than just documenting one after the fact.
6. It supports audit, compliance, and vendor conversations
Auditors, cyber-insurance underwriters, and enterprise customers doing vendor due diligence increasingly ask process-maturity-shaped questions even when they don’t use that term, “how do you know your change process is followed,” “what happens when an incident is missed.” An organization that has already scored itself against a defined model has a structured, evidenced answer instead of an anecdote.
7. It gives you something to benchmark against
A maturity score on its own is a data point. Compared against a known scale, the same one used by CMMI-based or ITIL 4 Maturity Model assessments elsewhere, it becomes a benchmark, which is what turns “we think we’re doing fine” into “we’re a Level 3 on Process, which is consistent with mid-sized IT organizations that haven’t yet formalized automation,” a genuinely useful sentence to bring into a planning conversation.
A Practical Illustration: Same Tool, Two Different Maturity Levels
This example is illustrative, not a real company, but it’s a pattern that shows up constantly in ITSM maturity work, so it’s worth walking through concretely.
Picture two mid-sized IT organizations. Both run the same ITSM platform. Both have a service desk, an on-call rotation, and a documented incident process sitting in a wiki somewhere. On paper, they look similar.
Organization A is Level 2 on Process and Level 2 on Automation. The documented process exists but isn’t consistently followed, severity is assigned inconsistently depending on who takes the call, escalation happens by instinct rather than by a defined threshold, and post-incident reviews happen only after the worst outages. The tool is configured, but ticket routing is manual, so the same ten minutes of triage happens on every incident regardless of how well-understood the issue is.
Organization B, running the identical platform, is Level 4 on Process and Level 3 on Automation. Severity definitions are written down and used consistently. Escalation triggers automatically past a defined time threshold. Every incident above a certain severity gets a blameless post-incident review, and the findings feed back into a tracked backlog. Routine, recurring incident types are auto-triaged and routed, so human attention goes to the incidents that actually need judgment.
Same software license. Very different organizations. A maturity model is what makes that difference visible and describable, without one, both teams would likely describe themselves the same way: “we have a process, we use the tool.” The model is what turns two similar-sounding self-descriptions into two specific, comparable, and actionable scores.
Common Misconceptions About Maturity Models
| Misconception | Why It’s Off |
|---|---|
| “A low score means the team is bad at their job.” | Maturity models score the process, not the people running it. A skilled team operating without defined escalation criteria will still score Level 2 on Process. That’s a structural gap, not a competence problem. |
| “Level 5 is always the goal.” | Optimized-level process discipline has a real cost to build and maintain. For a low-risk, low-volume process, Level 3 consistency is often the economically sensible target, not every process needs to be pushed to the top of the scale. |
| “One overall score tells you what you need to know.” | A single blended number is exactly what hides the People-vs-Tool-vs-Process distinction that makes the model useful for budget decisions. Dimension-level scores are where the actual value is. |
| “Maturity models are only for huge enterprises.” | The scale and the questions don’t change with headcount. A five-person IT team can score its incident process on the same criteria as a five-thousand-person one, the assessment just takes less time to run. |
| “It’s a one-time certification, like passing an exam.” | Unlike a certification, a maturity score isn’t permanent, it reflects current process state and is meant to be re-measured periodically as process, tooling, and staffing change. |
How DesQcon Approaches This
DesQcon’s own maturity framework follows this same structure, a five-level scale, scored independently across six capability domains (People, Process, Tool, Automation, AI, and Governance) rather than blended into one number. The full scoring logic, including exactly how domain questions map to levels, is documented on the ITSM Maturity Assessment Methodology page, and the same scale is explained with a worked process-vs-tool example in ITSM Process Maturity vs. Tool Maturity: Why You Need Both.
You can see the model applied directly with the free Incident & Major Incident Management maturity assessment, no sign-up required to see your score, with an optional email if you’d like a copy sent to you. The same six-domain, five-level structure extends across DesQcon’s paid process assessments, covering Problem, Change, Service Request, Knowledge, and Asset & Configuration Management, so results stay comparable across process areas instead of each one using a different rubric.
Frequently Asked Questions
Is a maturity model the same thing as a maturity assessment?
No, the model is the scale and the criteria; the assessment is the act of applying that model to a specific organization to produce a score. This post covers the model itself. For the step-by-step process of actually running an assessment, scoping, gathering evidence, scoring, benchmarking, and building a roadmap, see What Is an ITSM Maturity Assessment? A Practical Framework (+ Scorecard).
How often should an organization reassess its maturity?
There’s no universal rule, but annually is a common cadence for a full reassessment, with lighter spot-checks after major changes, a platform migration, a reorg, or a significant process rewrite, since those are the events most likely to move a score in either direction.
Does ITIL require organizations to use a maturity model?
ITIL doesn’t mandate a specific maturity model or certification, but continual improvement has been part of the framework since ITIL v3’s Continual Service Improvement publication, and ITIL 4 carries that forward through its continual improvement practice. Maturity assessment is the standard way organizations following ITIL put that practice into action, even though ITIL itself stays deliberately unprescriptive about which model to use.
Can a maturity model apply to a single process, or does it have to cover all of ITSM at once?
It can, and usually should, be applied one process at a time. Incident management, change management, and asset management each have their own maturity profile, and scoring them together tends to blur the picture rather than sharpen it. Most practical assessments, including DesQcon’s, are scoped to a single process area at a time.
Sources
- Philip B. Crosby, Quality Is Free (1979), origin of the quality management maturity grid concept
- Carnegie Mellon University Software Engineering Institute, “Capability Maturity Model”, https://en.wikipedia.org/wiki/Capability_Maturity_Model
- CMMI Institute, “Levels of Capability and Performance”, https://cmmiinstitute.com/learning/appraisals/levels
- Beyond20, “An Overview of the ITIL 4 Maturity Model and Assessment (and why they’re important)”, https://www.beyond20.com/blog/itil-4-maturity-model-and-assessment-overview/
- Wikipedia, “Capability Maturity Model Integration”, https://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration