The CTO of a 300-person SaaS company gets a question from the board ahead of a funding round: “How mature is our engineering organization?” The platform lead says the company has CI/CD, runs on Kubernetes and uses Terraform. The head of QA says regression still takes four days before each release. The on-call engineers say a quarter of releases need a hotfix. All three answers are true, and none of them answers the question.
That is the problem a DevOps maturity model solves. Tool inventories describe what a company has bought, and anecdotes describe its last bad week. A maturity model describes how reliably the organization turns code into value in production — across all the dimensions that matter, not only the one a particular leader looks after.
Below we present a five-level DevOps maturity model across seven dimensions, a 28-question self-assessment checklist with a scoring method we calculated on a worked example, the latest DORA benchmarks and a roadmap for moving between levels. It is written for CTOs and engineering leaders who need an honest baseline, not a vendor’s sales deck.
What is a DevOps maturity model and why do CTOs need one?
A DevOps maturity model is a structured description of how software delivery practices evolve, from manual and person-dependent to automated, measured and continuously improved. It does two things that a list of tools cannot.
First, it makes gaps visible across dimensions. Organizations rarely mature evenly. A company can deploy several times a day and still have no automated security testing, or run a polished internal platform while incidents are handled by whoever happens to be online. A maturity model forces you to look at every dimension with the same yardstick.
Second, it turns improvement into a sequence. Each level is a set of capabilities that the next one builds on. That ordering matters: frequent deployments without automated tests speed up the delivery of defects, and an internal developer platform without standardized pipelines only automates chaos.
For a CTO, a maturity assessment answers three practical questions:
- Where are we, honestly? A baseline agreed by engineering, operations, security and product, rather than the most optimistic view of any one of them.
- What should we fix first? The weakest dimension usually limits the whole delivery system, and it is rarely the one that gets the most attention.
- What should we invest in, and in what order? Hiring, tooling and training budgets follow from the gaps, not from vendor roadmaps.
It is worth being clear about what a maturity model is not. It is not a certification and not a score to put on a slide. The moment a maturity level becomes a target that teams are rewarded for, it stops measuring anything. Use it as a diagnostic tool, repeated every six to twelve months, and pair it with outcome metrics that are hard to game.
How does a DevOps maturity model relate to CMMI and DORA?
Most DevOps maturity models, including ours, borrow their five-level structure from CMMI (Capability Maturity Model Integration), originally developed at Carnegie Mellon University’s Software Engineering Institute. CMMI defines five maturity levels: Initial, Managed, Defined, Quantitatively Managed and Optimizing. The logic is the same in DevOps: first make work repeatable, then standardize it, then measure it, then improve it systematically.
The difference is focus. CMMI describes process capability in general; a DevOps maturity model describes the specific technical and cultural capabilities that determine how fast and how safely software reaches production. Our level names reflect that:
| Our level | CMMI equivalent | Short description |
|---|---|---|
| 1. Ad hoc | Initial | Manual, person-dependent delivery |
| 2. Repeatable | Managed | Basic automation in some teams |
| 3. Standardized | Defined | Shared pipelines, everything as code |
| 4. Measured | Quantitatively Managed | Decisions driven by SLOs and delivery metrics |
| 5. Optimizing | Optimizing | Continuous experimentation, self-service at scale |
DORA plays a different role. DORA (DevOps Research and Assessment) is a research program, now run by Google Cloud, that has surveyed technology professionals for more than a decade. Its findings were popularized in the 2018 book Accelerate by Nicole Forsgren, Jez Humble and Gene Kim, which identified 24 capabilities that drive software delivery performance. DORA measures outcomes, such as how often you deploy and how often deployments fail. A maturity model assesses capabilities, such as whether your environments are created from code.
You need both. Capabilities without outcomes can turn into box-ticking: a team can have every tool on the checklist and still deploy monthly. Outcomes without capabilities tell you that something is wrong but not what to change. In our model, DORA metrics are the evidence that confirms a maturity level — not the level itself.
One naming note for readers in Europe: DORA is also the acronym of the EU’s Digital Operational Resilience Act, which has applied to financial entities since 17 January 2025. The two are unrelated, although a mature delivery organization makes the regulation’s ICT risk and incident-reporting requirements far easier to meet.
Which DORA metrics show where you stand, and what changed in 2024 and 2025?
For years DORA used “four keys”: deployment frequency, lead time for changes, change failure rate and time to restore service. Two changes since then matter for anyone building a measurement system today.
In 2023, time to restore service was redefined as failed deployment recovery time. The older definition did not distinguish between failures caused by a software change and those caused by external events such as a data center outage. The new metric measures only recovery from a deployment that failed.
In 2024, DORA added a fifth metric, deployment rework rate, and regrouped the metrics into two factors:
- Throughput: change lead time (from commit to production), deployment frequency and failed deployment recovery time.
- Instability: change fail rate (the share of deployments causing failures in production) and deployment rework rate (the share of deployments that are unplanned work to fix bugs).
The 2024 Accelerate State of DevOps report grouped respondents into four performance clusters:
| Cluster (2024) | Share of respondents | Change lead time | Deployment frequency | Change fail rate | Recovery time |
|---|---|---|---|---|---|
| Elite | 19% | Less than a day | On demand | 5% | Less than an hour |
| High | 22% | 1 day to 1 week | Daily to weekly | 20% | Less than a day |
| Medium | 35% | 1 week to 1 month | Weekly to monthly | 10% | Less than a day |
| Low | 25% | 1 to 6 months | Monthly to every six months | 40% | 1 week to 1 month |
Two details are worth noting. The high cluster shrank from 31% in 2023 to 22% in 2024, while the low cluster grew from 17% to 25%. And for the first time, the medium cluster had a lower change fail rate than the high cluster — a reminder that speed and stability do not always move together.
The 2025 report, renamed State of AI-assisted Software Development and based on responses from nearly 5,000 technology professionals, went further. It replaced the four clusters with seven team profiles, from “Foundational challenges” and “Legacy bottleneck” to “Pragmatic performers” and “Harmonious high-achievers”, combining delivery metrics with team well-being and product outcomes. The authors’ reasoning is directly relevant to maturity assessment: delivery metrics tell you what is happening, but not why.
What are the five levels of DevOps maturity?
Each level describes a coherent state of the whole delivery system. Most organizations sit at different levels in different dimensions; the descriptions below are the typical profile when a level is reached across the board.
Level 1: Ad hoc. Releases are events. Deployments are manual or semi-manual, prepared by a few people who know how, and scheduled outside business hours. Environments are configured by hand and differ from each other. Testing is mostly manual and happens at the end. Incidents are discovered by customers. Knowledge lives in people’s heads, so vacations and resignations are delivery risks.
Level 2: Repeatable. Some teams have automated builds and unit tests on every commit. Deployment scripts exist, but each team has its own. Part of the infrastructure is in version control. There are centralized logs and basic uptime alerts. Delivery works, but it depends on which team you ask, and cross-team changes are slow.
Level 3: Standardized. A shared pipeline template is used by most teams. Every environment is created from code, and manual changes in production are the exception. Automated regression tests gate merges. Security scanning runs in the pipeline. Blameless postmortems follow major incidents. An internal platform team offers self-service for the most common tasks — the “golden path” that makes doing the right thing the easiest thing.
Level 4: Measured. Decisions are driven by data. Services have service level objectives (SLOs) agreed with product owners, and alerts fire on user-facing symptoms rather than server metrics. DORA metrics are collected automatically from the pipeline and incident tools, not from surveys. The platform is run as a product, with a roadmap and adoption metrics. Teams own their services end to end.
Level 5: Optimizing. Deployment is a non-event, done on demand with progressive delivery techniques such as canary releases and feature flags. Improvement experiments are part of every quarter’s plan. Known failure modes are remediated automatically. Compliance evidence is produced continuously by the pipeline rather than collected before audits. The organization learns from incidents faster than it creates new ones.
Level 5 is not a goal for every organization. For many companies, a solid Level 3 with Level 4 measurement in the most critical services is the economically sensible target. The right level depends on how much your business depends on the speed and reliability of software change.
Which seven dimensions should you assess?
A maturity assessment is only as good as its dimensions. Too few, and you miss the weak link; too many, and nobody completes it. We use seven, each representing a capability area that DORA’s research and our delivery projects show to be a common constraint:
- Culture and collaboration — shared ownership between development and operations, learning from incidents, stable priorities. DORA’s 2024 research found that unstable organizational priorities cause meaningful decreases in productivity and substantial increases in burnout, and that this effect persists even with strong leaders and good documentation.
- CI/CD — how code moves from commit to production: build automation, pipeline standards, deployment frequency and rollback. Our glossary entry on the CI/CD pipeline covers the basics.
- Infrastructure as code — whether environments are reproducible from version control and protected from drift. See infrastructure as code (IaC).
- Testing — automated tests at the right levels, quality gates, test data and test reliability.
- Observability and incident response — logs, metrics and traces, SLOs, on-call practices and postmortems.
- Security (DevSecOps) — security testing, secrets management, software supply chain and compliance built into the delivery flow. Our DevSecOps implementation checklist goes deeper into this dimension.
- Platform and developer experience — self-service for environments and pipelines, documentation, and how much cognitive load the delivery system puts on product teams.
Platform engineering deserves a separate note. DORA’s 2025 research found that 90% of organizations report using an internal developer platform and 76% have dedicated platform teams. The 2024 report showed that such platforms improve individual productivity and organizational performance, but can also reduce change stability and throughput if they are implemented without attention to developer independence. In other words, having a platform is not a maturity level; how teams experience it is. We cover the discipline in more detail in our article on platform engineering as the natural evolution of DevOps.
How do you run the self-assessment checklist?
The checklist below contains 28 yes/no questions — four per dimension, one for each level from 2 to 5. Level 1 is the default and needs no question. Answer each question for your organization as it works today, not as documented in a strategy deck. If the answer is “yes for some teams”, treat it as “no” unless it applies to the teams that deliver most of your business-critical change.
| Dimension | Level 2: Repeatable | Level 3: Standardized | Level 4: Measured | Level 5: Optimizing |
|---|---|---|---|---|
| Culture | Dev and ops share one channel and backlog for production issues | Blameless postmortems follow every major incident, with tracked actions | Teams own services end to end, with SLOs agreed with product | Improvement experiments are planned every quarter and reviewed |
| CI/CD | Every commit triggers an automated build and unit tests | Most teams use one standard pipeline; production deployments are scripted | Short-lived branches; production deployments at least weekly, with automated rollback | On-demand deployment with canary releases or feature flags |
| Infrastructure as code | Infrastructure for some environments is in version control | All environments are created from code; drift is detected | Ephemeral environments are created automatically for each change | Policy as code checks cost and compliance on every infrastructure change |
| Testing | Unit tests for critical modules run in the pipeline | Automated regression tests gate every merge | Flaky tests are tracked and fixed; quality gates use agreed thresholds | Contract tests and resilience experiments run continuously |
| Observability | Centralized logs and basic uptime alerts | Correlated logs, metrics and traces; runbooks for on-call | Alerts on SLOs and user-facing symptoms; DORA metrics collected automatically | Known failure modes are remediated automatically; incident trends feed the roadmap |
| Security | Dependency scanning is in place; no secrets in repositories | SAST and dependency scans block the pipeline above agreed thresholds; secrets manager in use | A software bill of materials (SBOM) is produced for every build; container and IaC scanning | Supply chain provenance and continuous compliance evidence are produced by the pipeline |
| Platform | Shared scripts and documentation for common tasks | A platform team offers self-service environments and pipelines | The platform has a roadmap, user feedback and adoption metrics | A new service reaches production through self-service, without tickets |
Run the assessment as a workshop rather than a survey. Invite a representative from each group that touches delivery — product engineering, operations or SRE, QA, security and the platform team — and require evidence for every “yes”: a pipeline definition, a dashboard, a postmortem document. Disagreements are the most valuable output. When the platform team answers “yes” and a product team answers “no” to the same question, you have found a gap between what exists and what is actually used.
A workshop like this fits into one working day. The first hour agrees the scope: which value streams are assessed and who owns them. The next three to four hours go through the 28 questions, dimension by dimension, with evidence on screen. The last hour discusses disagreements and picks two dimensions to improve in the coming quarter. It should be facilitated by someone who owns none of the assessed areas; otherwise the conversation quickly turns into a defence of past decisions.
Record not only the answers but the reasoning and evidence behind them. At the next assessment, six or twelve months later, you will compare not just scores but whether the underlying facts changed. That protects you from a score that rises only because the assessors, or their interpretation of the questions, changed.
If the organization has several independent product areas, assess each one separately. Differences between areas are often larger than differences between dimensions within one area — and they show where proven practices can be spread inside the company instead of being bought from outside.
How do you score the results?
Scoring follows two rules that keep the result honest.
Rule 1: levels are gated. Count only consecutive “yes” answers from Level 2 upward. A “yes” at Level 4 does not count if Level 3 is “no”. The dimension score is 1 plus the number of consecutive “yes” answers, so it ranges from 1 to 5. The gate reflects how capabilities work in practice: ephemeral environments built on top of manually configured production are not Level 4 infrastructure.
Rule 2: the weakest link caps the total. The overall maturity level is the average of the seven dimension scores, but no higher than one level above the weakest dimension. A delivery system is only as fast and safe as its slowest part.
Here is a worked example based on a profile we often see in growing SaaS companies:
| Dimension | Answers (L2 / L3 / L4 / L5) | Score |
|---|---|---|
| Culture | yes / yes / no / no | 3 |
| CI/CD | yes / yes / yes / no | 4 |
| Infrastructure as code | yes / no / yes / no | 2 |
| Testing | yes / no / no / no | 2 |
| Observability | yes / yes / no / no | 3 |
| Security | yes / no / no / no | 2 |
| Platform | no / no / no / no | 1 |
The company answered “yes” to 11 of 28 questions. The gated scores add up to 17 points, an average of 2.43. The weakest dimension, platform, scores 1, which caps the overall level at 2. The organization is at Level 2, despite having Level 4 CI/CD.
The example shows why both rules matter. Without the gate, infrastructure would score higher thanks to ephemeral environments that are created on top of hand-built production. Without the cap, the company would report an average close to 2.5 and a Level 4 pipeline — and the board would hear “we are almost at Level 3”. In reality, the fast pipeline delivers changes that are tested mainly by hand and scanned only for vulnerable dependencies, and every new service requires tickets to three teams.
The priorities follow directly: first the platform (1 → 2), then testing and security (2 → 3), because a Level 4 pipeline feeding Level 2 quality and security controls mostly accelerates the delivery of defects. That matches what DORA’s 2024 report said about AI adoption: fundamentals such as small batch sizes and robust testing remain crucial.
How do DORA benchmarks map onto the maturity levels?
Maturity levels describe capabilities; DORA clusters describe outcomes. They correlate, but the mapping is not exact, and any mapping — including ours below — is a heuristic rather than a result of DORA’s research. We use it to sanity-check self-assessments: if a team rates itself Level 4 but deploys monthly with a 40% change fail rate, the self-assessment is wrong.
| Maturity level | Typical DORA profile (based on 2024 clusters) | Warning signs of overrating |
|---|---|---|
| 1. Ad hoc | Low: months of lead time, deployments monthly or less, recovery in weeks | Releases need a “release weekend” |
| 2. Repeatable | Low to medium: deployments monthly to weekly | Each team deploys differently; hotfixes bypass the pipeline |
| 3. Standardized | Medium to high: deployments weekly to daily | Pipeline is standard but manual approvals take days |
| 4. Measured | High to elite: lead time under a week, recovery in less than a day | DORA metrics exist but come from surveys, not systems |
| 5. Optimizing | Elite: on-demand deployments, lead time under a day, recovery in under an hour | Speed is high, but rework rate keeps rising |
Measure the metrics per service or value stream, not as a company average. An average hides exactly what you are looking for: the payment service that deploys quarterly next to the marketing site that deploys hourly. And track deployment rework rate alongside change fail rate. A team can keep its change fail rate low by labelling urgent fixes as “planned work”; the rework rate exposes that.
For the business case behind these metrics — how shorter lead times and lower failure rates translate into revenue and cost — see our article on the business value of DevOps and DORA metrics.
What roadmap takes you from one level to the next?
Each transition has a different center of gravity. Trying to apply Level 4 practices at Level 1 is one of the most expensive mistakes in DevOps transformations.
From Level 1 to Level 2: make delivery repeatable. Put all code and deployment scripts in version control. Automate the build and unit tests for every commit in the most critical services. Centralize logs and set up basic alerting. Write down how a release is done, then script it. The goal is to remove single points of human failure, not to buy a platform.
From Level 2 to Level 3: standardize. Create one pipeline template that covers most services and make it the easiest option. Move every environment to infrastructure as code and stop manual changes in production. Build an automated regression suite that gates merges. Add dependency and static security scanning to the pipeline. Introduce blameless postmortems. This is usually when a small platform team pays for itself, because standardization is a product that someone has to own.
From Level 3 to Level 4: measure and own. Define SLOs for user-facing services with product owners, and alert on them. Collect DORA metrics automatically from source control, the pipeline and the incident system. Shift ownership so that teams run what they build. Treat the platform as a product with users, a roadmap and adoption metrics. Produce a software bill of materials for every build.
From Level 4 to Level 5: optimize. Introduce progressive delivery with canary releases and feature flags. Automate remediation for recurring failure modes. Run resilience experiments. Generate compliance evidence from the pipeline. Plan improvement experiments every quarter and measure their effect on delivery and well-being metrics.
How long does it take? In our projects, raising one dimension by one level typically takes one to two quarters of focused work. Moving the whole organization up a level usually takes a year or more, because the slowest dimensions — often culture, testing and security — set the pace. The practical rule is to work on no more than two dimensions at a time, starting with the one that caps your overall score.
What mistakes make maturity assessments useless?
Most failed assessments fail in predictable ways:
- Assessing tools instead of practices. “We use Terraform” is not the same as “all environments are created from code”. Ask for evidence of use, not licences.
- Letting one group answer for everyone. The platform team rates the platform, security rates security — and every dimension looks mature from the inside. Mix the perspectives.
- Averaging across teams. A company-wide Level 3 can hide one critical team at Level 1. Assess by value stream or product area, then aggregate.
- Turning the level into a target. When bonuses depend on the maturity score, the score rises and delivery does not. Keep the assessment diagnostic.
- Ignoring the human side. DORA’s 2025 profiles combine delivery metrics with burnout and friction for a reason. A team that deploys daily while burning out is not mature; it is borrowing from the future.
- Assessing once. A single assessment is a snapshot. The value comes from repeating it every six to twelve months with the same questions and comparing the results.
A useful check: if the assessment did not produce at least one uncomfortable finding, it was probably not honest.
How does AI change DevOps maturity in 2026?
AI coding assistants have changed the context of every maturity assessment. According to DORA’s 2025 report, 90% of respondents use AI at work and more than 80% believe it has increased their productivity, although 30% report little or no trust in AI-generated code.
The central finding of that report is that AI acts as an amplifier: it magnifies an organization’s existing strengths and weaknesses. The 2024 report had already found that AI adoption improved individual productivity, flow and job satisfaction, but had a negative effect on software delivery throughput and stability.
For a maturity model, the consequence is straightforward. AI increases the volume of change entering the delivery system. At Level 1 or 2, that means more untested code reaching manual release processes, more rework and more incidents. At Level 3 and above, where automated tests, security scanning and standardized pipelines act as guardrails, the same increase in volume can turn into faster delivery. The 2025 report also found a direct correlation between a high-quality internal platform and an organization’s ability to realize the value of AI.
In practice, we recommend adding two questions to the assessment workshop, without changing the scoring: Do AI-generated changes pass through the same quality and security gates as any other change? and Do we measure the effect of AI tools on rework rate, not only on developer speed? If both answers are “no”, the maturity roadmap should put testing and security ahead of further AI rollout.
When does it make sense to bring in external DevOps engineers?
Most maturity gaps are not caused by a lack of knowledge of what good looks like. They are caused by a lack of capacity: the same engineers who should build the standard pipeline are busy keeping the current one running. External support helps in three situations.
When the weakest dimension needs skills you do not have. Platform engineering, observability and DevSecOps are specializations. Hiring a senior platform engineer can take months, while the maturity roadmap is waiting. Experienced DevOps engineers joining your team for the duration of the transition can build the foundations and transfer the knowledge.
When a level transition needs a burst of work. Moving from Level 2 to Level 3 involves a lot of one-off effort: migrating environments to infrastructure as code, building the pipeline template, onboarding teams. That workload peaks and then drops, which makes it a natural fit for DevOps team augmentation rather than permanent hires.
When you need an independent assessment. Internal assessments tend to be generous in the areas that the assessors own. An outside view calibrated on many organizations makes the baseline credible to the board and to the teams.
Our guide to DevOps staff augmentation describes how to structure such engagements, and our article on building a DevOps center of excellence explains how to keep the capability in-house once the transition is done.
The key takeaways:
- Maturity is a property of the whole delivery system, not of a tool. Assess seven dimensions with the same yardstick.
- Use gated scoring and a weakest-link cap. In our example, a Level 4 pipeline sat inside a Level 2 organization.
- Confirm capabilities with outcomes. DORA’s five metrics — including the deployment rework rate added in 2024 — show whether your self-assessment is realistic.
- Move one level at a time, two dimensions at a time, starting with the dimension that caps your score.
- Treat AI as an amplifier. It accelerates mature delivery systems and exposes weak ones.
At ARDURA Consulting we have been supporting engineering organizations in Europe, the Middle East and the USA for more than ten years, including DevOps, SRE and platform engineers who work inside client teams. If you want an independent maturity assessment or engineers who can close the gap in your weakest dimension, talk to our team.