Key points
- FinOps is about value, not only cost cutting; the FinOps Foundation describes the goal as getting the most value out of technology to drive efficient growth.
- The FinOps Framework is built from six principles, three iterative phases (Inform, Optimize, Operate), four domains of capabilities, personas, scopes and a Crawl, Walk, Run maturity model.
- Start with allocation and visibility, then optimization, then governance; mature the capabilities that matter most to your business first.
- Measure progress with allocation coverage, commitment coverage, forecast variance, realized savings and unit cost.
What FinOps means in practice
The word is a blend of Finance and DevOps, and like DevOps it describes a way of working more than a job title or a tool. It is also known as cloud financial management, cloud financial engineering or cloud cost management. The practice is stewarded by the FinOps Foundation, part of the Linux Foundation.
In a traditional IT model, finance approved capital purchases up front and engineering worked within that capacity. In the cloud, any engineer can create resources that start billing immediately, and the bill arrives weeks later. FinOps closes that gap: cost data flows to engineers quickly, finance gets forecasts grounded in real usage, and the business decides which spend is worth it.
FinOps has also moved beyond public cloud. The FinOps Foundation now frames it around technology spend in general, including SaaS, licensing, data center and AI. In the State of FinOps 2026 survey, 98% of respondents manage AI spend, and the share that manage or plan to manage other categories reached 90% for SaaS, 64% for licensing and 48% for data center (FinOps Foundation, 2026).
The FinOps Framework at a glance
The FinOps Framework, published and maintained by the FinOps Foundation, is the reference model most organizations use. It has seven building blocks:
Scroll sideways to see the full table.
| Element | What it defines |
|---|---|
| Principles | Six values that guide decisions and behavior |
| Phases | Inform, Optimize and Operate: the iterative lifecycle |
| Domains | Four outcome areas that group the work |
| Capabilities | The specific activities within each domain, such as Allocation or Rate Optimization |
| Personas | Who takes part: core personas and allied personas |
| Scopes | Segments of technology spend, aligned to business constructs, to which the practice is applied |
| Maturity | Crawl, Walk, Run stages for each capability |
The six FinOps principles
The FinOps Foundation lists six principles. The names below are the Foundation’s; the explanations are ours.
- Teams need to collaborate. Finance, technology, product and business leaders work together, at the speed and level of detail each technology category requires.
- Business value drives technology decisions. Decisions are guided by unit economics and value-based metrics, not aggregate spend alone. Spending more can be the right call.
- Everyone takes ownership for their technology usage. Accountability is pushed to the edge: engineers own the cost of what they build, from architecture design through ongoing operations.
- FinOps data should be accessible, timely, and accurate. People make better decisions when cost data reaches them quickly, in context and in a form they trust.
- FinOps should be enabled centrally. A central team spreads best practice, maintains shared data and tooling, and handles rate and discount optimization at organizational scale.
- Take advantage of the variable cost model of the cloud. Consumption-based pricing and flexible capacity are an opportunity to reduce waste and deliver more value, not a risk to be locked down.
The three phases: Inform, Optimize, Operate
The phases are a loop, not a sequence you finish. The Foundation notes that practitioners cycle through them rapidly, and that different teams can be in different phases at the same time.
Inform
Examine technology cost, usage and efficiency data. This is visibility and allocation: ingesting billing data, mapping it to owners, reporting, budgeting, forecasting and benchmarking. Without Inform, every later conversation is an argument about whose numbers are right.
Optimize
Identify opportunities to improve efficiency and value. That includes usage optimization (using fewer or smaller resources) and rate optimization (paying less for the resources you need, for example through commitment discounts).
Operate
Implement the changes identified in Optimize, take incremental action and measure results. Operate is also where governance, policy, automation and training turn one-off wins into routine behavior.
Domains and capabilities
Capabilities are the concrete activities a FinOps practice performs. The Framework groups them into four domains:
Scroll sideways to see the full table.
| Domain | Capabilities |
|---|---|
| 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; Rate Optimization; Usage Optimization; Sustainability; Licensing & SaaS |
| Manage the FinOps Practice | FinOps Practice Operations; Governance, Policy & Risk; FinOps Assessment; Automation, Tools & Services; FinOps Education & Enablement; Invoicing & Chargeback; Intersecting Disciplines; Executive Strategy Alignment |
Scopes sit alongside domains. The Foundation defines a scope as a segment of technology spending aligned to business constructs such as a product, cost center or environment. Public cloud is the default starting scope; organizations add others, such as SaaS, data center, licensing or AI, when doing so helps them make better decisions.
Personas: who does FinOps
FinOps is cross-functional by design. The Framework defines two groups of personas:
- Core personas: FinOps Practitioner, Engineering, Finance, Product, Procurement and Leadership. Together they provide the disciplines needed to use cloud effectively.
- Allied personas: ITAM (IT asset management), ITFM (IT financial management), ITSM (IT service management), Security and Sustainability. They work in adjacent disciplines and coordinate with FinOps practitioners as needed.
A practical split: the FinOps practitioner runs the cadence and shared data; engineers act on usage findings; finance owns budgets, forecasts and chargeback; procurement negotiates commitments and contracts; product owners set unit cost targets; leadership sets priorities and resolves trade-offs.
The FinOps maturity model: crawl, walk, run
The maturity model lets an organization start small and grow in scale, scope and complexity. Maturity is assessed per capability, and the Foundation explicitly advises against pushing every capability to Run: prioritize the capabilities that provide the highest business value. The Foundation gives example measures for each stage:
Scroll sideways to see the full table.
| Measure | Crawl | Walk | Run |
|---|---|---|---|
| Cost allocated to a known owner | At least 70% | At least 85% | More than 90% |
| Commitment discount coverage | About 60% | More than 75% | More than 80% |
| Forecast variance | Below 20% | Below 10% | Below 5% |
| Typical characteristics | Minimal tooling, reactive processes, a few capabilities in place | Standardized capabilities, broader adoption, some automation | Organization-wide adoption, high automation, cost built into decisions |
FinOps vs cloud cost management
The terms are often used interchangeably, and the Foundation lists cloud cost management as an alternative name. In practice, teams usually mean something narrower by cloud cost management: the tools and activities for seeing and reducing spend. FinOps is the operating model around them.
Scroll sideways to see the full table.
| Dimension | Cloud cost management (as commonly used) | FinOps |
|---|---|---|
| Goal | Visibility and lower spend | Maximum business value from technology spend |
| Owner | Often a cloud, platform or finance team | Shared across engineering, finance, procurement, product and leadership |
| Scope | Cloud bills | Cloud plus other scopes such as SaaS, licensing, data center and AI |
| Key metric | Total spend and savings | Unit economics, allocation, forecast accuracy and realized savings |
| Output | Dashboards and recommendations | Decisions, accountability and a repeatable operating cadence |
Cost optimization techniques themselves, such as rightsizing, commitments and spot capacity, are covered in our cloud cost optimization guide.
How to start a FinOps practice in 90 days
This plan follows the Inform, Optimize, Operate loop. It assumes one accountable practitioner with part-time support from engineering and finance.
Days 1–30: Inform
- Name an executive sponsor and a FinOps owner. Write down the one or two outcomes leadership cares about, such as forecast accuracy or gross margin.
- Get billing data from every cloud account into one place, and enable detailed exports. Where available, use FOCUS-formatted exports to simplify multi-cloud reporting.
- Agree a mandatory tag or label set (owner, cost center, environment, application) and activate cost allocation tags where the provider requires it, as AWS does.
- Measure your baseline: total spend by team and service, the share of spend you can allocate, commitment coverage and top cost drivers.
- Turn on native budgets and anomaly alerts, such as AWS Cost Anomaly Detection or Microsoft Cost Management anomaly alerts, routed to named owners.
Days 31–60: Optimize
- Clean up low-risk waste: unattached volumes, old snapshots, idle instances and unused environments.
- Schedule non-production environments to stop outside working hours.
- Review rightsizing recommendations with the owning teams and agree which to action.
- Only after rightsizing, model commitment purchases for the steady baseline and agree a purchasing policy with finance and procurement.
- Record identified savings and, once changes land, realized savings from the following bills.
Days 61–90: Operate
- Set a cadence: weekly findings review with engineering, monthly spend and forecast review with finance, quarterly review with leadership.
- Publish showback reports to each team, and decide whether and when to move to chargeback.
- Put guardrails in the delivery path: tag enforcement in infrastructure-as-code, cost review for large infrastructure changes, and approval thresholds.
- Choose one or two unit metrics, such as cost per customer or per transaction, and start reporting the trend.
- Run a maturity self-assessment and choose the three capabilities to mature next quarter.
FinOps KPIs to report
- Allocation coverage: allocated cost ÷ total cost. The maturity model’s examples run from at least 70% at Crawl to more than 90% at Run.
- Commitment discount coverage: eligible usage covered by commitments ÷ total eligible usage.
- Commitment utilization: commitment used ÷ commitment purchased.
- Forecast variance: (actual − forecast) ÷ forecast, reported monthly.
- Realized savings: savings confirmed in subsequent bills, reported alongside identified savings.
- Waste ratio: cost of idle or unused resources ÷ total cost, trended over time.
- Anomaly response: time from anomaly detection to resolution.
- Unit cost: allocated cost ÷ business volume (customers, orders, requests).
FinOps tooling categories
The Framework treats tooling as a capability of its own (Automation, Tools & Services). Most practices combine several of these categories:
- Native provider tools for billing data, recommendations, budgets and anomaly alerts, such as AWS Cost Explorer, Microsoft Cost Management, Google Cloud Billing reports and OCI Cost Analysis.
- Billing data standards and pipelines. FOCUS, the FinOps Open Cost and Usage Specification, normalizes billing data across vendors and is supported by AWS, Microsoft Azure, Google Cloud, Oracle and others.
- Kubernetes cost allocation, such as OpenCost, a CNCF incubating project.
- Multi-cloud cost platforms that combine allocation, optimization, governance and workflow across providers.
- Infrastructure-as-code cost estimation for reviewing cost before deployment.
- Business intelligence and data warehouses for custom reporting and unit economics.
For a vendor-neutral comparison and evaluation checklist, read our cloud cost management tools guide.
Where Varcio fits. The Varcio platform is FinOps software for AWS, Azure, Google Cloud, OCI and Kubernetes: it runs on read-only credentials, ranks costed findings by savings, confidence and effort, gates changes behind approvals with an immutable audit log, and tracks identified against realized savings. If you want help designing the practice itself, Varcio Cloud Services offers FinOps consulting.
Frequently asked questions
What is FinOps in simple terms?
FinOps is the way an organization manages the cost and value of its cloud and other technology spend. Engineering, finance and business teams share timely cost data, take ownership of what they use and make trade-offs between speed, cost and quality together. The name combines Finance and DevOps.
What are the six FinOps principles?
According to the FinOps Foundation, the principles are: teams need to collaborate; business value drives technology decisions; everyone takes ownership for their technology usage; FinOps data should be accessible, timely, and accurate; FinOps should be enabled centrally; and take advantage of the variable cost model of the cloud.
What are the three phases of FinOps?
The phases are Inform, Optimize and Operate. Inform provides visibility and allocation of cost, usage and efficiency data. Optimize identifies opportunities to improve efficiency and value. Operate implements those changes and measures the results. Teams cycle through the phases continuously rather than completing them once.
What is the FinOps maturity model?
The FinOps Foundation uses a Crawl, Walk, Run model. Each capability can be at a different stage. As examples, the Foundation describes Crawl as allocating at least 70% of cost to a known owner with forecast variance below 20%, Walk as at least 85% allocation with variance below 10%, and Run as more than 90% allocation with variance below 5%.
Is FinOps only about cutting cloud costs?
No. The FinOps Foundation describes the goal as getting the most value out of technology to drive efficient growth. Sometimes that means spending more, for example to ship a revenue-generating feature faster, as long as the unit economics make sense.
Who is responsible for FinOps?
FinOps is shared. The FinOps Foundation defines core personas: FinOps practitioner, engineering, finance, product, procurement and leadership. A central FinOps function enables the practice, while engineering teams own their usage and finance owns budgeting and forecasting.
Do you need a dedicated FinOps team?
Not at first. Many organizations start with one practitioner or a part-time owner. As spend and complexity grow, a central team becomes common: Flexera’s 2026 State of the Cloud Report found that 63% of respondents rely on a FinOps team.
What is FOCUS in FinOps?
FOCUS, the FinOps Open Cost and Usage Specification, is an open specification from the FinOps Foundation that normalizes billing data across cloud, SaaS, data center and other technology vendors. Providers including AWS, Microsoft Azure, Google Cloud and Oracle support it, which makes multi-cloud cost reporting easier.
Sources
- What is FinOps? — FinOps Foundation, 2026
- FinOps Framework — FinOps Foundation, 2026
- FinOps principles — FinOps Foundation
- FinOps phases — FinOps Foundation
- FinOps domains and capabilities — FinOps Foundation
- FinOps personas — FinOps Foundation
- FinOps scopes — FinOps Foundation
- FinOps maturity model — FinOps Foundation
- State of FinOps 2026 — FinOps Foundation, 2026
- FOCUS: FinOps Open Cost and Usage Specification — FinOps Foundation
- Flexera finds cloud value is rising while AI waste grows (2026 State of the Cloud Report) — Flexera, 2026
- Cost optimization pillar: design principles — AWS Well-Architected Framework
- Organizing and tracking costs using AWS cost allocation tags — AWS documentation
- AWS Cost Anomaly Detection — Amazon Web Services
- Overview of Cost Management — Microsoft Learn
- OpenCost — OpenCost (CNCF)
Provider pricing and discount figures were checked against the linked documentation on 15 September 2026. Providers change pricing and programs regularly; confirm current terms before making purchasing decisions.