FinOps maturity is the level at which a team practises one FinOps capability; the FinOps Foundation's Framework, licensed CC BY 4.0, describes those levels as Crawl, Walk and Run. It is judged per capability, not per company: the same organisation can run its cost allocation at Walk and its forecasting at Crawl, and the Foundation says explicitly that Run is not the goal everywhere. The level matters for the bill because it decides how much effort goes into which capability: too low a level leaves cost without an owner and variances without an explanation, too high a level ties working hours to automation that no pending decision needs.
How it works
The Foundation treats FinOps as iterative work that matures each time it is repeated. Crawl, Walk, Run means beginning with a quick, narrow step, checking what it achieved, and widening the scope only where the return justifies the extra effort.
The three levels
The Foundation describes each level along four lines: how widely the capability is followed, how edge cases are handled, how ambitious the KPIs are, and how much rests on tooling and automation. At Crawl, reporting and tooling are thin, KPIs and processes basic, not every major team follows the capability, and the work aims at easy gains. At Walk the organisation follows it, its KPIs are set medium to high, the hard edge cases are known and their cost of resolution estimated, some are consciously left aside ("informed ignoring" in the Foundation's term), and processes or automation carry most of it. At Run every team follows it, the hard edge cases are worked, KPIs are ambitious and automation comes first.
Maturity per capability, not per company
According to the Foundation, the level is set per capability, and even activities within one capability can stand at different levels. As a shorthand for where a team stands, it offers a FinOps Assessment and a rubric, with sample goals from its community per level on the share of cost allocated to a known owner, commitment discount coverage and forecast accuracy; those samples are orientation, not thresholds.
At the core of the description, the Foundation warns against treating Run as the target for every capability. Its example is anomaly detection at Walk that has reliably caught the few cost spikes the organisation has seen; maturing it further would raise its level without improving the measure of success, and the effort is missing where another capability would bring an immediate benefit. What should mature is what delivers the highest business value.
For a company of 10 to 200 people, each level can be pinned to observable artefacts; the table describes what is visible, not which values have to be reached:
| Capability | Crawl | Walk | Run |
|---|---|---|---|
| Allocation | Allocation by account, subscription and project; unallocated cost stays a line of its own; allocation coverage is read off monthly | A tag standard with a few mandatory keys, a documented rule for shared cost, gaps that are named and accepted | Every new resource carries its allocation from creation; a policy checks it and reports violations to the owner |
| Reporting & Analytics | One cost report per owner, pulled monthly from the console or the export | Reports per scope reach their owners unprompted, with the previous month and the budget, in a cost definition finance and engineering share | Teams query their own cost, unit costs sit beside the amounts |
| Budgeting | One budget per scope, the variance is discussed in the monthly loop | Budgets with thresholds and notifications to the owner, a forecast beside them | Forecast-based alerts with a prepared action; reconciliation with the plan is part of month-end close |
| Anomaly Management | The provider's anomaly detection is switched on, alerts land with one person | Anomalies reach the scope's owner and end with a recorded decision: explained, accepted or fixed | Thresholds per scope, an anomaly opens a case automatically, response time is a KPI |
| Rate Optimization | One documented commitment decision; coverage and utilisation are looked at monthly | Coverage and utilisation are KPIs in the loop, purchases follow a written rule | Purchases run by rule and partly automated, their effect is demonstrated in amortized cost |
Placing your own team
Placement needs no questionnaire, only three questions per capability and an artefact as evidence. Is the capability performed, and by whom? Do all teams follow it, or only the one that introduced it? What happens at an edge case, such as a resource without an owner, and was that decided or does it simply happen? The evidence is the artefact itself: the report that was sent, the rule that is written down, the record of the decision.
That most capabilities stay at Crawl at this size is a decision, not a weakness: a few accounts, a few teams and one monthly invoice fit in a manual pass, and the business value rarely warrants automating it. The exceptions are Allocation and Reporting & Analytics, because every other capability reads from them. Which capabilities count at this size is set out in FinOps without a FinOps team; the full list is ordered in The four FinOps domains and their capabilities.
What it means for your cost
Maturity is not a column in the billing data, but it can be read from it: the share of unallocated cost shows the level of Allocation, the number of reports that a decision followed shows the level of Reporting, and the number of variances explained at month end against those left open shows Budgeting and Anomaly Management. Those three values, recorded monthly, are a maturity assessment with a month-on-month comparison.
The decision that follows is not "higher" but "where first". A capability moves up a level when a concrete decision needs it: chargeback presupposes Allocation at Walk, because internal charging without a documented shared-cost rule produces disputes; a larger commitment presupposes Reporting at Walk, because otherwise nobody can demonstrate its effect; tagging policies of the kind described in Tags and labels belong to Run and pay off only once account, subscription and project no longer suffice. How the levels sit within the Framework is shown in What FinOps is.
Where it goes wrong
- Maturity as an overall grade. Symptom: the company calls itself "at Walk" without being able to say in which capability. Cause: the level was assigned per company instead of per capability.
- Run as the goal. Symptom: an automation project for anomalies or tagging is under way while allocation coverage is not measured. Cause: effort followed the level instead of the business value; the Foundation warns against exactly that.
- Assessment instead of artefact. Symptom: the self-assessment says Walk, but the report is produced by hand by one person and stops when they are on holiday. Cause: maturity was judged by intent, not by the artefact and whether all teams follow it.
- One level for all scopes. Symptom: production is cleanly allocated, the development environments not at all, and yet one level is claimed for everything. Cause: the Foundation allows a capability's KPIs and maturity to vary by scope; the placement did not separate the scopes.
Sources
Read on 2026-10-16. FinOps Foundation: FinOps Maturity Model, FinOps Framework, FinOps Scopes.