The FinOps maturity model is a Crawl, Walk, Run framework for scoring each FinOps capability, not the whole program, against defined lenses and a target score tied to business value, as defined by the FinOps Foundation. The next step is straightforward: run an assessment across your capability domains, score what you find, and stop chasing Run where Walk already does the job.
TL;DR:
- Most organizations at the Crawl stage rely on manual processes, like spreadsheets and irregular tagging, for cost visibility and anomaly detection.
- Achieving the Walk stage involves standardizing tags, automating dashboards, and enforcing policies, but adoption across teams often remains a challenge.
- Reaching the Run stage requires deep automation, integrating KPIs into business planning, and embedding FinOps ownership into engineering teams.
- Prioritize high-impact, low-effort capabilities first, and avoid automating processes before they are well-defined and stable.
- A centralized FinOps team improves maturity more effectively than fully decentralized models, especially when supported by executive sponsorship and cross-functional collaboration.
Table of Contents
- What Is the FinOps Maturity Model, and Why Does It Exist?
- What Do Crawl, Walk, and Run Actually Look Like?
- How Do You Score Capabilities: Lenses, Weights, and Target Scores
- How Should You Prioritize Capabilities and Set Target Scores?
- How to Run a FinOps Maturity Assessment Step by Step
- What Do Organizations at Each Maturity Stage Actually Look Like?
- What Accelerates Movement Through the Maturity Stages?
- What Tools and Technologies Support Maturity Improvement?
- How Does Organizational Structure Shape FinOps Maturity?
- Practitioner Perspective: Mistakes to Avoid and Realistic Goals
- How EverythingCloud Helps You Move Through the Maturity Model Faster
- Where to Read More on FinOps Maturity and Assessment
- Sources
What Is the FinOps Maturity Model, and Why Does It Exist?
FinOps maturity isn’t a single number your organization earns once and keeps forever. It’s a descriptive framework applied capability by capability, meaning your commitment management practice might sit at Run while your SaaS spend allocation is still stuck at Crawl. That’s not a failure. It’s an accurate picture of where effort has and hasn’t gone.
The FinOps Framework exists because complexity varies wildly between organizations, and maturity should track that complexity rather than a generic checklist. A twelve-person startup running one AWS account doesn’t need the same anomaly-detection rigor as a 400-engineer enterprise spread across three clouds. The model gives both organizations a common language for describing where they stand without forcing them toward identical destinations.
Maturity assessments also connect directly to the six FinOps principles: collaboration across teams, business-value-driven decisions, shared ownership of cloud usage, taking advantage of the variable cost model, centralized enablement, and accessible, timely, accurate data. A capability can’t score well on the Adoption lens if the org still treats FinOps as a finance-only initiative, which is exactly the kind of gap the model is built to expose.
Typical capability domains you’ll assess include:
- Cost allocation and tagging
- Anomaly detection and alerting
- Commitment-based discounts (Reserved Instances, Savings Plans, committed-use discounts)
- Forecasting and budgeting
- Unit economics and business-value mapping
- Workload optimization and rate/usage efficiency
- SaaS and AI/token spend management
Each domain gets its own maturity score. Averaging them into one company-wide number defeats the purpose.
What Do Crawl, Walk, and Run Actually Look Like?
Reading the stage names doesn’t tell you much until you see them applied to real work. Here’s how the three stages typically show up inside actual capability domains, based on the FinOps Maturity Model.
- Crawl: Basic visibility exists, but processes are manual and reactive. Someone pulls a cost report before the monthly finance meeting, tags are inconsistent, and cost anomalies get discovered by whoever happens to notice the invoice first.
- Walk: Processes are standardized and partially automated. Tagging policies exist and are enforced through governance checks, dashboards update automatically, and a handful of KPIs are tracked, even if nobody has tied them cleanly to business outcomes yet.
- Run: Automation is deep and organization-wide. Anomalies trigger automated alerts routed to the right owner, commitment purchases adjust programmatically, and KPIs feed directly into business planning, not just engineering retrospectives.
Applied to allocation, Crawl means spreadsheets and best-guess tagging. Walk means an enforced tagging taxonomy with periodic audits.
Applied to forecasting, Crawl is a flat extrapolation of last month’s bill. Walk incorporates seasonality and known project timelines. Run ties forecasts to product roadmaps and adjusts automatically as usage patterns shift.
Automation itself follows the same arc. Crawl relies on someone remembering to right-size an instance. Walk uses scheduled scripts or provider Advisor recommendations reviewed weekly. Run means automated policies act on recommendations without a human in the loop, subject to guardrails.
Pro Tip: Don’t assess maturity from memory. Pull an actual tagging report or a real anomaly-response log before you score a capability. What teams believe about their own maturity and what the evidence shows are often two different stories.
How Do You Score Capabilities: Lenses, Weights, and Target Scores
Scoring a capability without a structure produces opinions dressed up as data. The FinOps Assessment Guide solves this with five lenses, each scored independently before you roll them into a single capability score.
Knowledge measures whether the people responsible for a capability actually understand it. Evidence: can the engineering lead explain how committed-use discounts affect their team’s unit costs? Documentation and training records count here.
Process measures whether the work happens the same way every time, regardless of who’s doing it. Evidence: a written tagging policy, an escalation path for cost anomalies, a documented commitment-purchase cadence.
Metrics measures whether you’re actually tracking the right numbers, and whether those numbers are trustworthy. Evidence: dashboards, allocation-accuracy percentages, budget-variance reports pulled from budgets APIs.
Adoption measures how widely the practice has spread beyond the FinOps team itself. Evidence: how many engineering teams review their own cost dashboards without being asked.
Automation measures how much of the work happens without a human clicking a button. Evidence: automated rightsizing, policy-as-code enforcement, programmatic commitment adjustments.
Score each lens 0 to 4, based on the scale conventions in the FinOps assessment playbook. A capability like anomaly detection might score Knowledge: 3, Process: 2, Metrics: 3, Adoption: 1, Automation: 1. Weight each lens by business priority, since a security-sensitive org might weight Automation higher for anomaly detection than a low-risk internal tool team would, then compute a weighted total against your target score, the deliberately chosen “good enough” ceiling for that capability rather than a universal 4-4-4-4-4.
Sample KPIs worth tracking once you’ve scored a capability:
- Allocation accuracy (percentage of spend mapped to a business unit or team)
- Mean time to anomaly detection and mean time to resolution
- Percentage of eligible spend covered by commitments
- Forecast variance against actuals, tracked monthly
One structural detail matters more than any single score: cloud teams report widespread FinOps adoption but persistent visibility gaps, with 82% of organizations practicing FinOps still struggling with basic cost visibility. That gap usually traces back to weak evidence on the Metrics lens, not a lack of effort elsewhere.
Evidence collection shouldn’t fall to one person guessing on behalf of every team. Assign an owner per lens, typically someone from finance for Metrics and Process, someone from engineering for Automation and Knowledge, and cross-check their findings against actual artifacts like tagging reports and allocation dashboards rather than self-reported confidence.
How Should You Prioritize Capabilities and Set Target Scores?
Not every capability deserves the same investment, and treating them equally is one of the fastest ways to burn a FinOps budget on low-value automation. Weight your prioritization using three factors: business impact, implementation effort, and regulatory or financial risk.
Build a simple prioritization view before committing resources:
- High impact, low effort: fix first (tagging enforcement, budget alerts)
- High impact, high effort: plan and stage (automated commitment management, unit economics)
- Low impact, low effort: batch into quarterly cleanup
- Low impact, high effort: deprioritize or accept Crawl deliberately
The target score concept exists precisely to stop teams from treating Run as the only acceptable outcome. Practitioner guidance from the FinOps community is direct on this point: there are “no runners” in the sense that no organization should aim for Run maturity across every single capability, since the cost of getting there often exceeds the value it returns. A capability serving a stable, low-risk workload can sit comfortably at Walk indefinitely.
Metric fixation is the other trap. Teams sometimes chase a perfect allocation-accuracy score while ignoring that the underlying process nobody trusts. A target score should reflect what the business actually needs, not what looks impressive in a board deck.
How to Run a FinOps Maturity Assessment Step by Step
An assessment only produces useful results when it follows a repeatable sequence rather than an ad-hoc audit someone runs once and forgets.
- Define scope. Decide whether you’re assessing a single workload, a business unit, or the whole organization. Broader scope takes longer but surfaces cross-team gaps sooner.
- Gather evidence per lens. Assign an owner for each lens and collect real artifacts, tagging reports, budget variance logs, automation scripts, rather than relying on interviews alone.
- Score each capability. Apply the 0 to 4 scale across Knowledge, Process, Metrics, Adoption, and Automation, then apply your business-priority weights to compute a total per capability.
- Identify the gaps. Compare current scores against target scores and rank the differences by business impact, not by which gap is easiest to close.
- Convert gaps into initiatives. Every gap needs a named owner and a realistic timeline. A gap without an owner never closes.
- Set a review cadence. Quarterly reviews work well for fast-moving capabilities like anomaly detection; annual reviews suit stable ones like forecasting governance.
Pro Tip: Score the same capability twice with two different evidence owners before trusting the result. Score disagreements almost always point to a Process gap you hadn’t noticed yet, not a scoring error.
Documented runbooks help here too. Teams that write down exactly how a managed FinOps operation handles evidence collection tend to get more consistent scores assessment after assessment, because the process doesn’t depend on one person’s memory.
What Do Organizations at Each Maturity Stage Actually Look Like?
A Crawl-stage organization is often a growth-stage company that adopted cloud fast and never circled back. Engineering teams provision freely, finance reconciles the bill after the fact, and cost conversations happen only when a monthly invoice spikes unexpectedly. Tagging exists in name but isn’t enforced, so allocation reports are best guesses dressed up as facts.
A Walk-stage organization usually has a dedicated FinOps function, even if it’s one or two people, and has standardized its tagging policy across at least the largest cloud accounts. Dashboards exist and get checked weekly. Commitment purchasing follows a documented cadence instead of happening whenever someone remembers. The gap at this stage is almost always Adoption: the FinOps team understands the numbers, but engineering teams outside that function still treat cost as somebody else’s problem.
A Run-stage organization has pushed FinOps ownership into engineering itself. Cost guardrails are enforced through policy-as-code, anomaly alerts route automatically to the team that caused them, and unit economics show up in product planning meetings alongside latency and reliability metrics. These organizations are rare not because the technology is hard to build, but because the cultural shift, treating cost as an engineering-owned metric rather than a finance report, takes far longer than any tooling rollout.
What Accelerates Movement Through the Maturity Stages?
The fastest advancement usually comes from sequencing investment correctly rather than working harder. Knowledge and Process gains almost always need to happen before Automation gains stick, since automating a broken process just breaks things faster.
Start by fixing tagging and ownership mapping before investing in anomaly-detection tooling. An automated alert that fires without a clear owner to receive it doesn’t move the needle. Establish the Process lens first: a written escalation path, a defined tagging taxonomy, a documented commitment-purchase cadence.
Cross-functional working groups accelerate Adoption faster than mandates from finance alone. When an engineering lead champions cost visibility inside their own team’s standup, the message lands differently than when it arrives as a compliance requirement from a team engineers rarely interact with.
Quick wins matter for momentum. Closing an obvious gap, like enforcing a tagging policy that’s been drafted but not enforced, builds credibility for the FinOps function before it asks for harder changes like automated commitment management. Sequence visible wins early.
Finally, treat automation as a lever you pull once Process and Metrics are stable, not before. Organizations that automate too early tend to automate inconsistency, since a script executing an undocumented process just repeats the same mistake at higher speed.
What Tools and Technologies Support Maturity Improvement?
Native cloud tooling covers a surprising amount of ground before you need anything else. Cost allocation tags, budgets APIs, and recommendation engines like Azure Advisor give you real evidence for the Metrics and Automation lenses without buying a separate platform. Most Crawl-to-Walk transitions happen using tools you already have access to.
Container-based workloads need their own attention. Kubernetes environments obscure cost allocation by default, since a single node might host workloads from five different teams, and closing that gap usually requires specific Kubernetes cost allocation tooling rather than relying on cloud-provider dashboards alone.
Beyond Walk, most organizations need a dedicated FinOps platform to handle multi-cloud aggregation, automated anomaly detection, and commitment optimization at scale. Spreadsheets and native dashboards don’t hold up once you’re managing spend across AWS, Azure, Google Cloud, SaaS licenses, and AI token consumption simultaneously. That’s the point where continuous monitoring and automated optimization stop being a nice-to-have and start being the only realistic way to keep pace with the assessment cycle itself.
How Does Organizational Structure Shape FinOps Maturity?
A centralized FinOps team with no engineering buy-in almost always caps out at Walk. They can build accurate dashboards and enforce policy on paper, but Automation and Adoption scores stall because the people who provision cloud resources every day aren’t the ones being measured.
A fully decentralized model, where every engineering team owns its own cost decisions with no central function, tends to produce inconsistent maturity: one team reaches Run on their own initiative while three others sit at Crawl because nobody coordinated the effort. The FinOps Foundation’s principle of centralized enablement exists specifically to prevent this fragmentation, pairing central standards with distributed execution.
Culture shows up most clearly in how disagreements get resolved. Organizations that treat a cost spike as a shared problem to solve, rather than a chance to assign blame, tend to close Process gaps faster because engineers report anomalies honestly instead of quietly patching them. Executive sponsorship matters too. When leadership treats FinOps as a cross-functional discipline reported alongside reliability and security, capabilities advance faster than when FinOps stays a line item buried in a finance team’s quarterly goals.
Practitioner Perspective: Mistakes to Avoid and Realistic Goals
The biggest mistake I see is treating Run as the finish line for every capability, when the real skill is knowing which capabilities deserve it and which don’t. Chasing full automation on a low-impact workload wastes engineering time that a high-impact gap actually needs. Cross-team collaboration closes more maturity gaps than any automation rollout because most Crawl-stage problems are ownership problems, not tooling problems. A balanced plan usually looks unglamorous: allocation and commitment management pushed hard toward Run, forecasting held steady at Walk, and a couple of low-impact capabilities left at Crawl on purpose. That’s not a compromise. That’s the model working as designed.
— Dan
How EverythingCloud Helps You Move Through the Maturity Model Faster
A practical accelerator for the assessment work this article just walked through is a platform that ingests evidence automatically across AWS, Azure, Google Cloud, Microsoft 365, and AI workloads, reducing the need to spend weeks manually pulling tagging reports and reconciling budget variance across accounts.
For teams building their Metrics and Automation lenses, some platforms provide real-time visibility, automated anomaly detection, and commitment management guidance that turns assessment gaps into tracked, owned initiatives rather than a spreadsheet nobody revisits. MSPs and technology partners may have access to ‘FinOps in a Box’ models that let them launch managed FinOps services under their own brand without building the automation and reporting layer themselves.
If you’re ready to move a capability from Walk toward Run without adding headcount, explore Everythingcloud’s managed FinOps platform and see what a continuous, automated assessment cycle looks like in practice.
Where to Read More on FinOps Maturity and Assessment
- The FinOps Maturity Model page defines the Crawl, Walk, Run stages and how they apply per capability.
- The FinOps Assessment Guide covers the scoring lenses, weighting, and target-score methodology in detail.
- The FinOps principles page ties maturity decisions back to the six foundational principles.
- FinOps for Enterprises: Hit 90% Allocation for Cloud Cost Visibility offers a practical look at closing allocation gaps specifically.
Sources
- FinOps Maturity Model
- FinOps Assessment Guide
- FinOps principles
- FinOps best practices (Microsoft Docs)
