FinOps is how an organization runs its technology spend as a business decision rather than an invoice to pay: engineering, finance and the business read the same cost data, decide together what it is worth, and act on it. This guide walks through the FinOps Foundation's Framework as its 2026 version sets it, shows what practitioners say they work on in 2026, and links each part to the articles of this blog that price the levers on a real bill.
The terms below are the FinOps Foundation's, quoted from finops.org as read on November 3, 2026, from the FinOps Framework 2026 (March 19, 2026). An older guide may use names renamed since: see What changed in 2025 and 2026.
What FinOps is
FinOps is an operational framework and cultural practice which maximizes the business value of technology, enables timely data-driven decision making, and creates financial accountability through collaboration between engineering, finance, and business teams
Three things in that definition set FinOps apart from cost cutting:
- Value, not a lower bill. A bill that grows with revenue can be a success; one that falls while the product breaks is not.
- A practice between teams. Engineers decide most of the spend, finance plans and accounts for it, the business decides what it is for.
- Technology, not only the cloud. The 2025 revision added "and technology" to the definition (FinOps Framework 2025), and the 2026 one updated it again, so that it now speaks of "the business value of technology" (FinOps Framework 2026).
The Framework is a set of elements that fit together, listed on the Framework overview: principles, scopes and technology categories, personas, domains and capabilities, with the phases and the maturity model one click away. The sections below take them one at a time.
The six FinOps principles
The principles are the values a practice is judged against. Four of them were reworded in 2025: "This is the first time the FinOps Principles have changed since they were originally crafted in 2019" (FinOps Framework 2025). As the FinOps Principles page states them:
The six FinOps principles and what each asks for
| Principle | In the Foundation's words |
|---|---|
| Teams need to collaborate | "Teams work together to continuously improve for efficiency and innovation." |
| Business value drives technology decisions | "Make conscious trade-off decisions among cost, quality, and speed." |
| Everyone takes ownership for their technology usage | Engineers take "ownership of costs from architecture design to ongoing operations." |
| FinOps data should be accessible, timely, and accurate | "Process and share cost data as soon as it becomes available." |
| FinOps should be enabled centrally | "A centralized FinOps function encourages, evangelizes, and enables best practices in a shared accountability model." |
| Take advantage of the variable cost model of the cloud | "Make technology decisions based not only on technical requirements, but also these cost model considerations." |
The fifth principle read "A centralized team drives FinOps" until 2025. The central team now enables; the people who build and run the systems act.
Who takes part: the FinOps personas
"Personas represent broad stakeholder groups that must collaborate, not individual people" (FinOps Personas): one person can hold several. The six core personas, with the practitioner who will "bridge business, engineering, and finance teams" in the middle:
At the centreFinOps Practitioner
Engineering
"designing, building, managing and optimizing technology infrastructure"
Finance
"works closely with FinOps Practitioners to quantify the business value"
Product
"prioritizing initiatives that align FinOps to business objectives"
Procurement
"procuring technology across technology categories"
Leadership
"sets and promotes overall business and technical objectives"
Five allied personas join when the work touches their discipline: IT Asset Management (ITAM), IT Financial Management (ITFM), Sustainability, IT Service Management (ITSM / ITIL) and Security.
How FinOps runs: Inform, Optimize, Operate
A practice works in three phases (FinOps Phases) and goes around them again and again:
Inform
"examine technology cost, usage and efficiency data": who spends what, on what.
Optimize
"identify and document a list of options for the organization to optimize its technology state".
Operate
"implementing changes identified in the Optimize phase", then keeping the gain: the next Inform measures it.
The loop is not one company-wide sequence: "Different members of a FinOps team can work on different phases, or at a different cadence". One team can be in Operate on its compute while another is still in Inform on a new data platform.
In short: Inform, then Optimize, then Operate, and again: every change is measured by the next pass, and each team can be at its own phase.
What FinOps covers: four domains and their capabilities
"Domains are the outcomes of a FinOps practice", each made of capabilities (FinOps Domains). The 2026 Framework has four domains and 22 capabilities, as the Framework overview lists them:
Understand Usage & Cost
- Data Ingestion
- Allocation
- Reporting & Analytics
- Anomaly Management
Quantify Business Value
- Planning & Estimating
- Forecasting
- Budgeting
- KPIs & Benchmarking
- Unit Economics
Optimize Usage & Cost
- Architecting & Workload Placement
- Usage Optimization
- Rate Optimization
- Licensing & SaaS
- Sustainability
Manage the FinOps Practice
- Executive Strategy Alignment
- FinOps Practice Operations
- Governance, Policy & Risk
- FinOps Education & Enablement
- Invoicing & Chargeback
- FinOps Assessment
- Automation, Tools & Services
- Intersecting Disciplines
The capabilities a first year rests on
- Allocation: "Define strategies to assign and share cost and usage using accounts, tags, labels, and other metadata". Without it, no other capability can say who spends what.
- Data Ingestion: "Collect, transfer, store, and normalize data from various sources". FOCUS, the billing data format, is the format the Foundation proposes for it.
- Anomaly Management: "Detect, identify, alert and manage unexpected or unforecasted technology cost and usage irregularities in a timely manner".
- Forecasting: "Creating a model of the anticipated future cost and value of IT systems leveraging statistical methods". It feeds Budgeting, a separate capability.
- Unit Economics: it "brings together what an organization spends on technology and the value that technology spending creates", such as a cost per API call.
- Rate Optimization: "the Capability used to manage the rates that you pay for the resources": Savings Plans, Reserved Instances, Committed Use Discounts, negotiated discounts, Spot.
- Usage Optimization "is a set of practices that ensure resources across all FinOps Scopes are properly selected", then right-sized, run only when needed and kept busy: it changes what is used rather than what it costs per unit.
Rate and usage are the two levers every bill has. The service articles of this blog put usage first: a commitment bought on usage about to be removed is paid for nothing.
What changed in 2025 and 2026
The 2025 revision renamed two domains and one capability (FinOps Framework 2025); the 2026 one added Executive Strategy Alignment and renamed six capabilities (FinOps Framework 2026):
Framework names before and after the 2025 and 2026 revisions
| Before | Now | Revision |
|---|---|---|
| Understand Cloud Usage and Cost (domain) | Understand Usage & Cost | 2025 |
| Optimize Cloud Usage and Cost (domain) | Optimize Usage & Cost | 2025 |
| Cloud Policy & Governance, then Policy & Governance | Governance, Policy & Risk | 2025, 2026 |
| Workload Optimization | Usage Optimization | 2026 |
| Architecting for Cloud | Architecting & Workload Placement | 2026 |
| Cloud Sustainability | Sustainability | 2026 |
| Benchmarking | KPIs & Benchmarking | 2026 |
| FinOps Tools & Services | Automation, Tools & Services | 2026 |
| (none) | Executive Strategy Alignment | 2026 |
In five of these lines the word "cloud" goes, since the practice now covers every technology an organization pays for; the others widen a name (Usage, Risk, KPIs, Automation) or add one.
Scopes and technology categories
- A Scope is "a defined segment of spending across technology categories," "aligned to business constructs–such as product, cost center, or environment–" (FinOps Scopes).
- The technology categories are what the spend is on: the 2026 Framework opened pages for Public Cloud, SaaS, Data Center, Data Cloud Platforms and AI (FinOps Framework 2026), and the Framework overview also shows Private Cloud and Licenses.
- What changed: in 2025, Public Cloud, SaaS and Data Center were themselves called Scopes (FinOps Framework 2025); since 2026 they are categories, and a Scope cuts across them.
A product that runs on AWS, pays for two SaaS tools and calls a hosted AI model is one Scope over three categories: one question, what does it cost and what does it earn, asked of all of it.
How mature a practice is: Crawl, Walk, Run
The Framework rates each capability on three stages, with example KPIs for each (FinOps Maturity Model):
Crawl
"Very little reporting and tooling"; a plan for the "low hanging fruit". Example KPI: at least 70% of cost allocated.
Walk
The capability "is understood and followed within the organization". Example KPI: at least 85% allocated.
Run
Followed "by all teams"; "Automation is the preferred approach". Example KPI: more than 90% allocated.
Example KPIs of the FinOps maturity model, by stage
| KPI | Crawl | Walk | Run |
|---|---|---|---|
| Cost allocated to a known owner | At least 70% | At least 85% | More than 90% |
| Commitment discount coverage of the target | About 60% | More than 75% | More than 80% |
| Gap between forecast and actual spend | Below 20% | Below 10% | Below 5% |
The stages are per capability: a practice can run its commitments well and still crawl on allocation. And more is not always better:
an organization's goal should never be simply to achieve a "Run" maturity in every Capability.
FOCUS: one format for billing data
Each provider writes its bill in its own format. FOCUS, the FinOps Open Cost & Usage Specification, is "an open specification for billing data" that "defines a common schema for billing data" (FOCUS Specification): columns such as Billed Cost, Effective Cost, List Cost, Charge Category and Service Name, the same whoever produced the data.
- What it is
- An operational framework: principles, personas, phases, domains, capabilities
- Who uses it
- The people of a FinOps practice, to organize their work
- What it changes
- How decisions on technology spend are made
- Current version
- 2026, published in March 2026
- What it is
- An open specification for billing data: a common schema of columns
- Who uses it
- Providers, which export their billing data in it, and the tools that read it
- What it changes
- How the cost data is read, the same way across providers
- Current version
- 1.4, ratified on June 4, 2026
What differs: the Framework says what to do with cost data; FOCUS says how the cost data is written. FOCUS saves nothing by itself: the savings come from the decisions taken on the data.
- Who maintains it: "FOCUS is a separate Project supported by the FinOps Foundation (which is itself a Project of the Linux Foundation)" (FOCUS FAQ).
- Who exports it: its home page lists AWS, Microsoft, Google Cloud, Oracle, Alibaba Cloud, OVHcloud, Snowflake and Databricks, among others.
- Version 1.4 (June 4, 2026) "adds 2 datasets, 47 columns, 6 attributes, 17 glossary entries, and 2 supported features", including Invoice Detail and Billing Period, which tie cost data to the invoices finance pays. Version 1.5 is announced with AI model identity and token consumption (Introducing FOCUS 1.4).
- Not every provider exports the latest version: AWS Data Exports offers a FOCUS 1.2 table with AWS columns, next to the Cost and Usage Report that the Cost Explorer article compares with the invoice.
In short: FOCUS is a format, not a method: it makes every provider's bill readable with the same queries, and the savings still come from what the practice decides on that data.
The state of FinOps in 2026
The FinOps Foundation's yearly survey, the State of FinOps 2026 Report, is its sixth. Only the figures the report writes out as text are given here, each with the question asked and the number of people who answered it (N).
- 1,192respondents"Representing $83bn+ in annual cloud spend"; the Foundation's 6th annual survey
- 98%manage AI spend, today or within 12 monthsUp from 63% in 2025 and 31% in 2024 (multi-select, N=632)
- 78%of FinOps teams report to the CTO or CIO8% to the CFO ("Where does your FinOps practice sit…?", N=523)
- 60%run a centralized enablement team21% a hub-and-spoke model ("current FinOps team structure", N=657)
What FinOps teams manage
The Framework's widening to every technology shows in the answers. Asked "What areas of technology spend does the FinOps team manage today and in the next 12 months?":
AI went from a minority to almost every team in two years:
What they work on
- Top current priority: "Workload optimization and waste reduction remain the single top current priority for FinOps teams."
- Top priority ahead: "FinOps for AI emerges as the top forward-looking priority."
- Where they sit: 78% report to the CTO or CIO, 8% to the CFO (N=523); 60% run a centralized enablement team and 21% a hub-and-spoke model (N=657).
- What they ask of their tools, the three most frequent free answers: granular monitoring of AI spend (tokens, LLM requests and GPU utilization), costing an architecture before it is deployed, and one view across every kind of technology spend.
- FOCUS: the report notes "Year-over-year growth in FOCUS usage", and the most requested next areas for it are "AI workloads, data center, and broader SaaS/PaaS support".
The report gives the priorities, the team sizes and the FOCUS figures only as chart images; they are left out here rather than read off a picture.
From the framework to a real bill
The Framework names capabilities; a bill needs levers, priced. The service articles of this blog price the levers that AWS documents, at its list prices for the Paris Region:
Where the blog's service articles meet the Framework's capabilities
| Capability | Where it is priced on this blog |
|---|---|
| Allocation | Cost allocation tags and Cost Categories; EKS costs split by namespace |
| Data Ingestion | The invoice and the Cost and Usage Report |
| Anomaly Management | Cost Anomaly Detection |
| Forecasting | Forecasts and Cost Comparison |
| Usage Optimization | How to reduce EC2 costs; How to reduce S3 costs; How to reduce RDS costs |
| Architecting & Workload Placement | AWS Graviton; NAT gateway and data transfer costs |
| Rate Optimization | Savings Plans and Reserved Instances; the same commitments on Graviton |
The largest lever is not always on that list. At EDF Power Solutions, a case told on the FinOps page, a simulation engine rewritten from C# to Rust went from about 7 h 30 to under 30 seconds per run, and its cloud costs fell by about half: Architecting & Workload Placement, through the software. The full story is chapter 6 of the book Something from Almost Nothing. The If I were FinOps cases apply the levers to a scenario, and the calculator prices a setup of your own.
Where to start
The maturity model gives the order: Crawl first, on the capabilities that carry the most money. For a team with a bill and no practice yet:
See the bill by ownerInform · Allocation
Turn on the billing export, group accounts and tags by team and product, and measure how much cost has a known owner (Crawl: at least 70%).
Agree on what a unit is worthQuantify · Unit Economics
One metric per product, such as a cost per customer, per order or per API call, says more than a total that grows with the business.
List the levers, with effort and riskOptimize · Usage
Usage first: what nothing uses, what is oversized, what runs at night for nobody. Then the design, then the rates.
Apply what the owners approve, then watch itOperate · Anomaly Management
An alert on each owner's spend keeps a gain from wearing off.
Commit lastOptimize · Rate
Cover with a commitment the usage that is left every hour, once the levers above have run.
The next pass starts from a bill that the last one changed.
FAQ
What is FinOps in simple terms?
A practice where engineering, finance and the business share the same cost data and decide together what technology spend is worth. The FinOps Foundation's definition: it "maximizes the business value of technology, enables timely data-driven decision making, and creates financial accountability" (What FinOps is).
Is FinOps just cost cutting?
No. Its second principle is "Business value drives technology decisions": a bill that grows with revenue can be the right outcome. Cutting waste is one domain of four (What FinOps covers).
What are the three phases of FinOps?
Inform, Optimize and Operate. They run as a loop, and different teams can be in different phases at once (How FinOps runs).
Is FOCUS a way to cut the cloud bill?
No. FOCUS is an open specification for billing data, a common set of columns that providers export their costs in. It makes the bills of several providers readable the same way; the savings come from the decisions taken on that data (FOCUS: one format for billing data).
Does FinOps apply beyond the public cloud?
Yes, since the 2025 and 2026 revisions: the definition speaks of technology, and the Framework has technology categories such as SaaS, data centers, data cloud platforms and AI. In the State of FinOps 2026 survey, 90% of teams manage SaaS spend today or within 12 months, and 48% data center spend (The state of FinOps in 2026).
What do FinOps teams focus on in 2026?
Workload optimization and waste reduction remain the top current priority, and FinOps for AI the top one ahead; 98% of teams manage AI spend today or within 12 months (N=632) (The state of FinOps in 2026).
What is the difference between Crawl, Walk and Run?
They are the three maturity stages of each capability. For allocation, the Foundation's example KPIs are at least 70% of cost with a known owner at Crawl, at least 85% at Walk and more than 90% at Run (How mature a practice is).
