The FinOps Maturity Model: A Practical Guide to the 5 Stages

Why a maturity model matters

The FinOps Foundation defines a maturity model with three phases - Crawl, Walk, Run - applied across the domains of Inform, Optimize, and Operate. It is a useful frame, but in practice organizations rarely move through it as cleanly as the three-phase model suggests. Cost visibility stalls. Optimization becomes a one-off project that someone runs once and forgets. "Operate" never quite arrives because the structural decisions that produce sustainable cost discipline were never made.

The five-stage model below extends that foundation into something more honest about how the journey actually unfolds. It is not theoretical. Each stage is defined by a specific combination ofvisibility, accountability, automation, and culture - the four forces that determine whether cloud cost work compounds or decays.

The five stages at a glance

Most organizations sit between Stage 2 and Stage 3. They can find waste when they look, but they cannot explain a cost spike without a week of investigation, and they have no mechanism to prevent the same waste from returning next month.

Stage 1 - Crawl: Cost blindness

You are here if: the monthly cloud bill arrives and nobody can confidently explain what changed, or a single team owns the bill with no visibility into which workloads drove it.

At this stage, cost is a finance problem, not an engineering one. Engineering decisions - instance types, region selection, storage classes - are made without cost as an input, because there is no feedback loop connecting the decision to the bill. The organization is effectively flying blind.

The work at this stage is not optimization. It is visibility: getting billing data into a place where someone can read it, establishing a tagging strategy (even an imperfect one), and making the bill a shared artifact rather than a finance-team secret. You cannot optimize what you cannot see.

How to move up

• Enable detailed billing export (GCP: BigQuery export, AWS: CUR, Azure: Cost Management export)
• Pick one tagging dimension that matters (team, project, or environment) and enforce it
• Build a single dashboard - even a rough one - that shows spend by that dimension over time
• Pick a monthly cost number and make it visible to the people making the decisions

Stage 2 - Walk: Reactive optimization

You are here if: someone runs a cost audit once a quarter, finds idle resources, oversized instances, and unattached storage, and reclaims budget - but the same waste returns the following quarter.

This is where most organizations plateau. The visibility from Stage 1 enables optimization, but optimization is a project, not a process. A person (often a cloud architect or an external consultant) looks at the data, identifies waste, and fixes it. The bill drops for a month. Then it creeps back up, because nothing structural changed.

The trap at this stage is confusing activity with progress. Right-sizing 50 instances feels like progress, and it is - for this month. But if the conditions that created the oversized instances are still in place, you will be right-sizing 50 different instances next quarter. Stage 2 is a treadmill.

How to move up

• Stop treating optimization as a quarterly event. Schedule a monthly review.
• For every waste item you fix, ask: what allowed this to happen? Then fix the cause, not the symptom.
• Introduce the first commitment-based savings (reserved instances, committed use discounts) for steady-state workloads.
• Begin attributing cost to teams, not just to resources.

Stage 3 - Run: Accountability and attribution

You are here if: every team can answer "what did we spend, and why?" without a week of investigation, and a cost spike triggers an alert that reaches the team responsible for it.

Stage 3 is the inflection point. The shift from Stage 2 to Stage 3 is not a tooling change - it is an accountability change. Cost data is no longer something a central team looks at; it is something each team owns. A team that provisions a resource knows what it costs, sees it on their dashboard, and is accountable for it in their planning.

The technical backbone of this stage is attribution: the ability to take a dollar of cloud spend and trace it to the team, product, or business unit that consumed it. This requires consistent tagging (or cloud-native equivalents like GCP projects or AWS accounts used as organizational boundaries), shared cost allocation rules, and dashboards that each team actually checks.

How to move up

• Move from tagging-by-good-intentions to tagging-as-a-gate: resources without required tags cannot be provisioned.
• Set per-team budgets with anomaly detection - not to enforce limits, but to trigger conversations when spend deviates.
• Start measuring unit economics in at least one place (cost per transaction, cost per user, cost per job).
• Make cost review a standing agenda item in engineering planning, not a separate finance meeting.

Stage 4 - Sprint: Prevention through automation

You are here if: the most common forms of waste cannot enter your environment in the first place - policy gates, infrastructure-as-code conventions, and automated guardrails catch them before they bill a single hour.

Stages 1-3 are about finding and fixing waste after it exists. Stage 4 is aboutpreventing it. This is where FinOps meets platform engineering. The infrastructure itself becomes the enforcement layer:

• Policy as code (OPA, Sentinel, cloud-native policies) blocks non-compliant resources at provisioning time.
• Infrastructure modules encode cost-conscious defaults - the "easy path" is also the cheap path.
• Automated rightsizing runs continuously, not quarterly, and surfaces recommendations that humans act on or explicitly dismiss.
• Commitment management is automated or semi-automated - the system tracks usage patterns and recommends commitment purchases.

The cultural shift here is significant: engineers are no longer asked to "be cost-conscious." Cost-consciousness is built into the platform they use, so the default behavior is the right one. This dramatically reduces the cognitive load of FinOps and makes the practice sustainable at scale.

How to move up

• Identify the top 3 recurring waste patterns from Stage 2-3 and build a policy gate for each.
• Adopt or build golden infrastructure modules where the default configuration is cost-optimized.
• Instrument commitment tracking - know what you have, what you use, and what you are leaving on the table.
• Begin shifting from monthly cost review to continuous cost signals (event-driven, not calendar-driven).

Stage 5 - Marathon: Unit economics and business alignment

You are here if: cloud cost is discussed in the same sentence as revenue, margin, and unit economics - and engineering decisions are made against business value, not against an abstract monthly budget.

Stage 5 is the destination, and very few organizations operate here consistently. At this stage, "did we spend too much?" is the wrong question. The right question is: "did each dollar of cloud spend produce more than a dollar of business value?"

This requires:

• Unit cost metrics defined and tracked: cost per transaction, cost per user, cost per query, cost per job.
• Margin visibility by product, feature, or customer segment.
• Forecasting that ties cloud spend to business growth, so scaling decisions are made against revenue projections, not historical budgets.
• Architecture decisions that weigh cost against performance, reliability, and speed - with cost as a first-class input, not a constraint applied after the fact.

The organization at Stage 5 does not have a "FinOps team" in the traditional sense. Cost discipline is distributed, automated where possible, and connected to the business in a way that makes it self-sustaining. That is the marathon: not a sprint to a target, but a steady, sustainable rhythm of cost-aware engineering.

Where most organizations actually sit

In our experience, the distribution looks roughly like this:

• Stage 1 (Crawl): ~20% of organizations. Common in early-stage startups and organizations that recently migrated to cloud without a cost strategy.
• Stage 2 (Walk): ~40% of organizations. The most common stage, and the one where most teams plateau. Activity without progress.
• Stage 3 (Run): ~25% of organizations. Teams that have made accountability work and can explain their bill without a week of investigation.
• Stage 4 (Sprint): ~12% of organizations. Mature platform engineering teams that have encoded cost discipline into the infrastructure itself.
• Stage 5 (Marathon): ~3% of organizations. The rare organization that has connected cloud spend to unit economics and makes architecture decisions accordingly.

If you are in Stage 2 and trying to decide where to invest, the answer is almost alwaysattribution. The single highest-leverage move is not better tooling or more audits - it is making each team accountable for the cost they generate, with the data to back it up. That is the door from Stage 2 to Stage 3, and once you walk through it, the rest of the journey becomes structurally possible.

The takeaway

The FinOps maturity model is not a checklist. It is a description of how the work of cloud cost management compounds - or fails to. Organizations that plateau at Stage 2 are not lazy or unskilled; they are stuck in a reactive loop that feels productive but does not build structural cost discipline. The way out is not more optimization. It is the unglamorous work of attribution, accountability, and the slow, deliberate shift from "find and fix" to "prevent and explain."

If you want to know which stage your organization sits in - and what the single highest-leverage move would be to move up - that is the kind of assessment we do. The first conversation costs nothing.

Published: 2026-07-15 - Alveon