FinOps Framework: FinOps Framework – Tutorial (about 60 minutes)

The FinOps Framework is an openly published operating model, maintained by the FinOps Foundation, that helps organisations get the most business value out of what they spend on cloud and other technology. Engineers, finance analysts, product owners, procurement specialists and leaders use it to share cost data, make trade-offs together and hold each team accountable for its own usage. After this tutorial you will be able to explain the Framework's principles, personas, phases, maturity model, domains, capabilities and scopes, and plan how a real organisation could start practising FinOps.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the FinOps Framework is published online by the FinOps Foundation, a project of the Linux Foundation. It is a living framework rather than a numbered standard: the Foundation revises it in place, normally with an annual update. The current version is the 2026 update, announced on 19–20 March 2026, which added the Executive Strategy Alignment capability, renamed several capabilities (Architecting for Cloud, for example, became Architecting & Workload Placement, which now also covers the onboarding of workloads that the 2025 Framework treated as a separate Onboarding Workloads capability), expanded the guidance on Scopes and added Technology Category pages (public cloud, SaaS, data centre, data cloud platforms and AI). It builds on the 2025 update, which widened the Framework from public cloud to all technology spending and introduced Scopes. The Framework is not an ISO or national standard and there is no certificate of conformity for an organisation that adopts it. Verified 2026-10-29 on finops.org.

Who it is for: cloud and platform engineers, software architects, finance and controlling staff, IT financial management and IT asset management people, procurement and vendor managers, product managers, engineering managers and anyone asked to "get the cloud bill under control" or to show what technology spending delivers.

Prerequisites: none. A basic idea of how cloud services are billed (you pay for what you use, by the hour, by the gigabyte or by the request) will make the examples easier to follow, and it is explained briefly in Lesson 1.

How to use this tutorial: read the seven lessons in order (about 45 minutes), study the five diagrams, then spend the remaining time on the reflection questions before you take the 25-question knowledge check. The Framework itself is free to read on the FinOps Foundation website, so keep it open in another tab while you study.

Learning objectives:

You will be able to explain why FinOps exists, what problem the variable cost model creates and what the Framework is meant to achieve.
You will be able to use the core vocabulary correctly, including showback, chargeback, allocation, unit economics, commitment discounts, Scopes and FOCUS.
You will be able to describe the building blocks of the Framework: six principles, core and allied personas, three phases, the Crawl–Walk–Run maturity model, four domains and their capabilities.
You will be able to plan how an organisation starts and runs a FinOps practice, including the team model, cadence and first capabilities.
You will be able to explain how FinOps maturity is assessed with the five assessment lenses, and which certifications exist for people and for vendors.
You will be able to compare FinOps with ITFM, ITAM, ITSM, FOCUS and cloud provider guidance and explain where they meet.

Lesson 1 – Origins, purpose and scope

The problem FinOps solves

In a traditional data centre, spending decisions were slow and centralised. A team wrote a business case, procurement negotiated a purchase, finance approved a capital budget and, weeks later, servers arrived. Cost was decided once, up front, by a small group of people, and engineers rarely saw a bill.

Public cloud changed that. Any engineer with the right permissions can start hundreds of virtual machines, a managed database or a GPU cluster in minutes. The provider charges for what is used, often per second or per request, and sends the bill a month later. Spending became variable (it rises and falls with usage), decentralised (thousands of small decisions by many people) and fast (a misconfigured job can burn a month's budget in a weekend). The same pattern now appears with software-as-a-service subscriptions, data platforms charged by compute credits and AI services charged per token.

Finance teams found that their annual budgets did not survive contact with this reality. Engineering teams found that nobody had told them what "too expensive" meant. Procurement found that the provider offered large discounts for commitments, but nobody could say how much usage was stable enough to commit. The result was a gap between the people who spend and the people who pay. FinOps is the discipline that closes that gap.

What FinOps is, and what it is not

The FinOps Foundation describes FinOps as an operational framework and cultural practice. In plain words, FinOps is a way of working in which engineering, finance, product and business teams collaborate, using timely and shared cost data, so that every technology decision considers both what it costs and what value it creates. The goal is not simply to spend less. A team that doubles its cloud bill while tripling revenue may be doing excellent FinOps; a team that cuts its bill by half while its product becomes unreliable is not.

The name joins "finance" and "DevOps". Like DevOps, FinOps is mostly about people and habits: shared goals, short feedback loops and automation. Tools help, but buying a cost dashboard does not create a FinOps practice.

Who maintains the Framework

The FinOps Foundation is a non-profit community of practitioners that operates under the Linux Foundation. Its members include end-user organisations, cloud providers, software vendors and consultancies. The Framework is written and revised by community working groups and published as a set of web pages: principles, personas, phases, maturity, domains, capabilities, scopes and technology categories. Because it is a living document, you should always read the current pages rather than an old PDF or poster, and you should expect names to change from one annual update to the next.

Scope: from cloud to all technology

The Framework began as guidance for public cloud spending. In 2025 it was widened to cover technology spending more broadly, and the 2026 update added Technology Category pages for public cloud, SaaS, data centre, data cloud platforms and AI, noting that this list is not exhaustive. The Foundation's mission was restated around the value of technology as a whole. As a result, a modern FinOps team might look at a cloud account, a SaaS contract, a data warehouse and an on-premises cluster with the same principles and many of the same capabilities, adapted to how each category is priced.

The Framework does not prescribe a tool, a cloud provider, an organisational chart or a fixed sequence of steps. It describes outcomes, responsibilities and practices that organisations adapt to their size, industry and maturity.

Lesson 2 – Key concepts and vocabulary

FinOps conversations mix finance, engineering and procurement language. Agreeing on terms early prevents many arguments later. The following terms are used throughout the Framework and this tutorial.

Variable cost model – pricing in which you pay for what you consume, so cost follows usage up and down instead of being fixed in advance by a purchase.
Allocation – assigning each cost to the team, product, cost centre or customer responsible for it, using account structure, tags, labels and shared-cost rules.
Tagging (labelling) – attaching key–value metadata such as team=payments or env=prod to resources so that billing data can be grouped and allocated.
Shared costs – costs that serve many teams, such as a shared Kubernetes cluster, networking or a support plan, which must be split by an agreed rule (evenly, proportionally or by a fixed ratio).
Showback – reporting to each team what it consumed and what it cost, without moving money between budgets.
Chargeback – actually charging each team's budget for its consumption through internal accounting entries.
Unit economics – cost expressed per unit of business output, such as cost per customer, per order, per stream hour or per thousand API calls, so that efficiency can be judged independently of growth.
Usage optimisation – using fewer or smaller resources for the same outcome, for example rightsizing an oversized instance, deleting idle storage or scheduling non-production systems to stop at night.
Rate optimisation – paying a lower price for the resources you do need, for example through commitment-based discounts, negotiated contract terms or cheaper pricing models such as interruptible capacity.
Commitment-based discount – a lower rate in return for committing to a level of usage or spend for a period (provider names include reserved instances, savings plans and committed use discounts). Coverage is the share of eligible usage that is covered; utilisation is the share of the commitment you actually use.
Anomaly – an unexpected change in cost or usage, such as a sudden spike caused by a runaway job, which should be detected and investigated quickly.
Forecast variance – the difference between forecast and actual spend, a common measure of how well spending is understood.
Persona – a role-based group of stakeholders described in the Framework, such as Engineering or Finance, with typical goals and responsibilities.
Capability – a functional area of activity that a FinOps practice performs, such as Allocation or Forecasting, grouped into four domains.
Scope – a defined segment of technology spending, aligned to a business construct such as a product, cost centre or environment, to which FinOps practices are applied.
FOCUS – the FinOps Open Cost and Usage Specification, an open specification for the format and meaning of billing data so that cost data from different vendors can be combined.

Two pairs that are often confused

Showback and chargeback both start from good allocation. The difference is whether money moves. Many organisations begin with showback to build trust in the numbers, then move to chargeback once teams agree that the allocation is fair. Usage and rate optimisation are also different levers, and they usually involve different people: engineers change usage, while procurement and finance change rates. The two interact, because committing to a discount for a resource you are about to remove wastes money, so the order of actions matters.

Why "value" is the key word

Most FinOps vocabulary is about cost, but the Framework repeatedly asks what the cost buys. Unit economics is the bridge. If a video platform's cloud bill rises 20 percent while its cost per stream hour falls 10 percent, the platform is growing efficiently. Without a unit metric, the same numbers would look like a problem. Learning to ask "cost per what?" is one of the most useful habits FinOps teaches.

Lesson 3 – Structure of the Framework

The Framework is a set of connected building blocks. Figure 1 shows how they fit together: principles guide everything; personas are the people; phases describe the repeating cycle of work; the maturity model describes how good each activity is; domains group capabilities; and Scopes and technology categories describe where the practice is applied.

Figure 1 – The building blocks of the FinOps Framework and how they relate to a FinOps practice.

The six principles

The principles are the values behind every practice. In summary, as currently published:

Teams need to collaborate. Finance, engineering, product and procurement work together, in near real time, with shared goals.
Business value drives technology decisions. Decisions are judged by value delivered, using unit economics and value metrics, not by cost alone.
Everyone takes ownership for their technology usage. Accountability is pushed to the edge: the team that consumes a resource owns its cost, against its own budget.
FinOps data should be accessible, timely and accurate. People can only act on data they can see quickly and trust; fast feedback drives better behaviour.
FinOps should be enabled centrally. A central team sets standards, negotiates rates and provides tools and education, so that distributed teams can act on their own usage.
Take advantage of the variable cost model of the cloud. Variable pricing is an opportunity: scale down when demand falls, experiment cheaply and adapt continuously instead of fixing spending once a year.

Notice the balance between principles 3 and 5. Responsibility for usage is decentralised, while rate negotiation, standards and enablement are centralised. Most real FinOps operating models are a version of this hub-and-spoke idea.

Personas

The Framework describes core personas, who always take part in practising FinOps, and allied personas, who work in neighbouring disciplines and coordinate with FinOps where their work intersects.

The FinOps Practitioner bridges business, engineering and finance, runs the practice and builds a data-driven culture.
Engineering designs, builds and operates systems and balances cost against performance, reliability and security.
Finance handles budgeting, forecasting, accounting and allocation, and quantifies the value of spending.
Product owns requirements and priorities and explains the value of technology decisions in business terms.
Procurement buys technology, manages vendor contracts and negotiates discounts.
Leadership sets objectives, makes prioritisation decisions and sponsors accountability.

The allied personas are IT asset management (ITAM), IT financial management (ITFM), IT service management (ITSM), Security and Sustainability. Figure 2 shows the practitioner at the centre of a network of collaboration, which is the Framework's first principle in picture form.

Figure 2 – Core personas collaborate through the FinOps Practitioner, who also coordinates with allied disciplines.

Phases

The work of FinOps moves through three phases: Inform (visibility and allocation), Optimize (finding opportunities in rates and usage) and Operate (acting on them and improving continuously). They form a loop, not a one-way project plan. Lesson 4 covers them in detail.

Maturity: Crawl, Walk, Run

The maturity model uses three plain-language stages. At Crawl, a capability is understood but only partly followed, reporting and tooling are basic and the team goes after the easiest wins. At Walk, the capability is understood and followed across the organisation, most requirements are covered by process or automation, and difficult edge cases are known and some are consciously left alone. At Run, all teams follow the capability, hard edge cases are being addressed, targets are ambitious and automation is the default. Maturity is judged per capability, so one organisation can be at Run for allocation and at Crawl for forecasting at the same time. The Framework is explicit that reaching Run everywhere is not the goal; the right level is the one that delivers enough business value.

Domains and capabilities

The Framework groups its capabilities into four domains, each answering a question. In the 2026 update there are 22 capabilities, shown in summary in Figure 3.

Understand Usage & Cost – what are we spending, where and on what? Capabilities: Data Ingestion, Allocation, Reporting & Analytics, Anomaly Management.
Quantify Business Value – what are we getting for it and what will it cost next? Capabilities: Planning & Estimating, Forecasting, Budgeting, KPIs & Benchmarking, Unit Economics.
Optimize Usage & Cost – how can we get more value per unit spent? Capabilities: Architecting & Workload Placement, Usage Optimization, Rate Optimization, Licensing & SaaS, Sustainability.
Manage the FinOps Practice – how do we run, govern and grow FinOps itself? Capabilities: Executive Strategy Alignment, FinOps Practice Operations, Governance, Policy & Risk, FinOps Education & Enablement, Invoicing & Chargeback, FinOps Assessment, Automation, Tools & Services, Intersecting Disciplines.

Figure 3 – The four domains of the 2026 Framework with their capabilities in short form.

Each capability page in the Framework follows a similar pattern: a definition, why it matters, how the personas take part, what Crawl, Walk and Run look like, typical measures of success (KPIs), and inputs and outputs. The separate technology category pages then explain how the capabilities, personas and KPIs adapt to each kind of spending. You do not need to memorise every page, but you should know the four domain names and be able to place any capability in the right domain.

What changed in 2026

The 2026 update is mainly a refinement. Executive Strategy Alignment was added to make sure FinOps work supports leadership priorities and multi-year investment decisions. Several capabilities were renamed, mostly to make them technology-neutral or broader: Workload Optimization became Usage Optimization, Architecting for Cloud became Architecting & Workload Placement (which now also covers workload onboarding, so the former Onboarding Workloads capability no longer appears separately and the total stays at 22), Cloud Sustainability became Sustainability, Benchmarking became KPIs & Benchmarking, Policy & Governance became Governance, Policy & Risk, and FinOps Tools & Services became Automation, Tools & Services. Older training material may still use the earlier names.

Scopes and technology categories

A Scope is a segment of spending that you choose to manage with FinOps practices, defined by a business question rather than by a vendor. Examples are "everything that runs the mobile app product", "all AI experimentation in the research division" or "the production environment of the retail platform". A Scope can span several technology categories (cloud compute, a SaaS observability tool and an AI API, for instance). Scopes can be temporary, can overlap and can be scaled back once they have done their job. The 2026 guidance adds a structured way to clarify the business context of a Scope first, then decide which personas, capabilities, maturity targets and cadence apply.

Technology categories describe the kind of spending: public cloud, SaaS, data centre, data cloud platforms and AI each have their own pricing models, data sources, personas and KPIs. The Framework's category pages explain how the common capabilities adapt to each one and how FOCUS can be used to bring their billing data together.

Lesson 4 – How it works in practice

The FinOps lifecycle

Figure 4 shows the three phases as a loop. Teams cycle through it quickly and repeatedly, often weekly or even daily for some activities, rather than once a year.

Figure 4 – The Inform, Optimize and Operate phases form a continuous loop in which results feed the next cycle.

Inform. The team ingests billing and usage data, allocates it to owners, builds reports and dashboards for each persona, sets budgets and forecasts, and starts to calculate unit costs. The output is shared understanding: everyone can see what they spend and why. Because prices and usage keep changing, Inform is revisited in every cycle, not completed once.

Optimize. Using that visibility, the team looks for ways to improve value. For cloud this may mean rightsizing, deleting unused resources, scheduling, choosing a different service or architecture, or buying commitment discounts. For SaaS and licences it may mean removing unused seats, consolidating overlapping vendors or renegotiating contracts. The output is a list of options with estimated savings, effort and risk. Options compete for the same engineering time, so they are prioritised against business goals and the rest go into a backlog.

Operate. Teams carry out the chosen changes, build automation and policies so that improvements stick, and adjust processes. Operate also covers changes to the practice itself, such as maturing a capability or adding a new Scope. The results flow back into Inform, where the effect on cost and unit metrics is checked.

Different people can be in different phases at the same time. The commitment-management analyst may be in Optimize while a product team is still in Inform for a new service. Frequent small actions are preferred to big annual exercises because they avoid analysis paralysis and build habits.

Team model

Most organisations create a small central FinOps team, sometimes called a FinOps centre of excellence or cloud cost office. It owns the cost data platform, allocation rules, reporting, commitment purchasing, policies and education. It does not own every optimisation; engineering teams own their usage, supported by the central team. Many organisations also appoint FinOps champions inside engineering and product teams, who act as local contacts and bring cost into planning conversations. Where the central team sits (finance, the CIO's office, a platform engineering group) varies; what matters is executive sponsorship and access to both finance and engineering.

Cadence and rituals

A FinOps practice runs on a rhythm. Typical elements are daily or near-real-time anomaly alerts routed to the owning team; weekly or fortnightly cost reviews in engineering teams, using their own dashboards; monthly reviews with finance comparing actuals to budget and forecast; quarterly reviews with leadership on unit economics, commitments and strategic decisions; and an annual planning and budgeting cycle informed by forecasts from the teams that will spend the money. The cadence should match how quickly spending can change and how material it is.

Key artefacts

A cost allocation strategy: account or subscription structure, tagging standard, rules for shared costs and a target for the share of spend that is allocated.
Persona-specific reports: engineers see resources and usage, finance sees budget versus actual and forecasts, leaders see trends and unit costs.
A commitment and rate plan: which discounts to buy, at what coverage target, who approves and how utilisation is monitored.
Policies and guardrails: for example mandatory tags, budget alerts, limits on expensive instance types in sandboxes, and approval steps for large commitments.
A KPI set: allocation percentage, forecast accuracy, commitment coverage and utilisation, waste or idle spend, and unit costs for key products.
A FinOps roadmap: which capabilities and Scopes to mature next, based on assessment results and business priorities.

Getting started

The Framework does not prescribe a fixed sequence, but a common and sensible path is: find an executive sponsor and agree on why FinOps matters for the organisation; set up data ingestion and basic allocation so that most spending has a known owner; publish showback reports to teams; pick one or two Scopes with clear business questions; address the obvious waste and the simplest rate opportunities; then add forecasting, unit economics and governance as trust in the data grows. This is Crawl in practice: start small, show value, then expand.

Example measures

The Foundation publishes example targets to illustrate the stages. For instance, the maturity page cites cost allocated to a known owner of at least 70 percent at Crawl, at least 85 percent at Walk and above 90 percent at Run, and forecast variance shrinking from under 20 percent to under 5 percent as maturity grows. Treat such numbers as illustrations to calibrate your own goals, not as requirements.

Lesson 5 – Assessment, certification and compliance

No compliance certificate for organisations

The FinOps Framework is guidance, not a requirements standard. There are no "shall" clauses, no accredited certification bodies and no certificate that says an end-user organisation "complies with" the Framework. If a supplier or consultant claims to certify your FinOps practice as compliant, ask exactly what they mean. What exists instead is a structured self-assessment approach, certifications for individuals, and certifications for vendors that build FinOps tools or offer FinOps services.

The FinOps Assessment capability

FinOps Assessment is itself a capability in the Manage the FinOps Practice domain. Its purpose is to establish where the practice is today, agree on a target state that fits the organisation's goals and chart the path between them. The Foundation's assessment working group publishes a guide and tool for this.

The recommended approach is focused rather than exhaustive. Instead of scoring all 22 capabilities across the whole company at once, you choose a target group (a small, representative set of people, for example one business unit with its engineers, finance partner and product owner) and a subset of capabilities that matter most to them. The core FinOps team usually assesses itself first, then expands to other groups.

The five lenses

Each assessed capability is examined through five lenses, each scored from 0 to 4, giving a maximum of 20 per capability:

Knowledge – how well the target group understands the capability and why it matters.
Process – whether consistent, documented processes exist to deliver it.
Metrics – whether measures are defined, collected and used to track it.
Adoption – how widely the capability is accepted and practised across the target group.
Automation – how much of the repeatable work is done by tooling rather than by hand.

Figure 5 – A focused FinOps assessment scores selected capabilities through five lenses and feeds a roadmap that is reassessed regularly.

The point is not to reach 20 everywhere. The assessment guidance itself suggests that a score of around 12 out of 20 may be good enough for a capability that is new on the roadmap. Targets should reflect business value, which matches the maturity model's message that Run is not automatically the goal. Using the same lenses each time also lets you show progress over time and compare target groups consistently.

How often to assess

The Framework links assessment cadence to maturity. Early on, an annual assessment of the core team may be enough. As the practice matures, the core team assesses itself half-yearly or quarterly and business units are assessed more regularly, eventually by trained assessors or champions within those units, with results shared back to the central team.

Certifications for people

The FinOps Foundation offers certifications for individuals. The best-known entry-level one is the FinOps Certified Practitioner, which tests understanding of the Framework's concepts and vocabulary. Others include an engineering-focused certification, a certification on analysing FOCUS data, a more advanced professional-level certification, and newer certifications on topics such as the value of AI and technology. Names, prerequisites, formats and prices change, so check the Foundation's training site before planning a learning path. These certifications show that a person knows the Framework; they say nothing about whether that person's employer practises FinOps well.

Certifications for vendors

The Foundation also certifies member organisations that sell FinOps tools (FinOps Certified Platform) or offer FinOps consulting and advisory services (FinOps Certified Service Provider). Requirements include Foundation membership, documented alignment with the Framework's capabilities and a number of individually certified staff; for platforms, publicly documented FOCUS support is an optional criterion that earns extra points. This helps buyers shortlist vendors, but it is not a certification of the buyer's own practice.

Governance and audit links

Although FinOps is not an audit standard, its outputs often support audits and controls elsewhere: accurate allocation supports cost accounting and transfer pricing; policies and approval workflows support internal control over spending; anomaly management can surface security incidents such as compromised credentials being used for crypto-mining. The Governance, Policy & Risk capability is where these connections are designed.

Lesson 6 – Worked example

This example is fictional and the figures are illustrative. It shows how the building blocks fit together in a realistic sequence.

The organisation

Kestrel Media is a video streaming company with about 300 engineers in 25 product teams. It runs most workloads on one public cloud provider, uses a second provider for machine-learning training, pays for a dozen SaaS tools (observability, collaboration, a data warehouse) and has recently started calling a hosted large-language-model API for content tagging. Technology spending has grown about 40 percent in a year. The chief financial officer cannot explain the growth to the board, engineering teams say they have never seen a bill, and two large cost spikes last quarter took weeks to explain.

Step 1 – Sponsorship and purpose

The chief technology officer and chief financial officer agree to sponsor a FinOps practice. They write a one-page purpose statement: give every team visibility of its technology costs, connect spending to business value for each product, and make forecasts reliable enough for board reporting. They appoint a FinOps lead from the finance team who has worked closely with engineering, add a platform engineer and a data analyst, and name a champion in each product team. This applies the principles of collaboration and central enablement from the start.

Step 2 – Inform: data and allocation

The team ingests billing exports from both cloud providers and the SaaS vendors into a central data store, converting them to a common FOCUS-aligned format so that columns such as billed cost, effective cost, service and resource mean the same thing everywhere. An initial review shows that only about half of spending can be tied to a product team. The team agrees a tagging standard with three mandatory keys (team, product, environment), restructures cloud accounts so that each product has its own production and non-production accounts, and writes a rule for shared costs: the shared Kubernetes platform is split in proportion to each team's requested CPU and memory. Within three months, more than 80 percent of spend has a known owner. Showback reports go to each team every week, and a monthly summary goes to finance and leadership.

Step 3 – Anomaly management

The team sets up automated anomaly alerts, routed to the owning team's chat channel rather than to the central team. In the first month an alert catches a misconfigured log pipeline that is writing duplicate data; the owning team fixes it the same day. Engineers start to trust the reports because they are timely and specific.

Step 4 – Scopes and unit economics

Leadership's main question is whether streaming is becoming more efficient as the company grows. The FinOps team defines a Scope called "streaming delivery", covering the compute, storage and network costs of the video platform plus the content delivery network and the observability tool used by those teams. With product managers it chooses a unit metric: cost per thousand stream hours. A second, smaller Scope covers "AI content tagging", spanning the cloud machine-learning training account and the hosted model API; its unit metric is cost per hour of video tagged. The first chart shows that total streaming cost is rising, but cost per thousand stream hours has fallen slightly, which reassures the board. The AI Scope shows the opposite: cost per tagged hour has doubled because a new, larger model was adopted without checking alternatives.

Step 5 – Optimize: building the options list

The team builds a backlog of options and estimates savings, effort and risk for each:

Rightsize over-provisioned database instances found through utilisation data (usage, engineering effort medium).
Stop non-production environments at night and at weekends (usage, low effort).
Delete unattached storage volumes and old snapshots after owner confirmation (usage, low effort).
Buy commitment-based discounts for the stable baseline of the streaming compute fleet after the rightsizing is finished (rate, procurement and finance).
Remove unused seats in two SaaS tools and consolidate two overlapping monitoring products at renewal (licensing and SaaS, procurement).
Evaluate a smaller model or batching for the AI tagging workload (architecting and workload placement, engineering).

The team deliberately sequences rightsizing before buying commitments, so that the company does not commit to capacity it is about to remove. Options are prioritised with product owners against roadmap work; not every saving is worth delaying a customer feature.

Step 6 – Operate: acting and making it stick

Product teams implement the usage changes during normal sprints with help from their champions. Procurement buys commitments covering about two-thirds of the stable baseline, with monthly utilisation monitoring. The platform team automates the night-time shutdown and adds a policy that blocks untagged resources in non-production accounts. The AI team tests a smaller model that meets the quality bar and halves cost per tagged hour. Finance starts building forecasts with each product team using their roadmaps, and forecast variance improves quarter by quarter.

Step 7 – Assess and plan the next cycle

After six months the FinOps lead runs a focused assessment with the streaming product group on four capabilities: Allocation, Anomaly Management, Forecasting and Rate Optimization. Allocation scores 15 of 20, strong on process and adoption. Forecasting scores 8, weak on metrics and automation. Leadership agrees to target 12 for Forecasting in the next half-year and to start a showback-to-chargeback discussion with finance. The FinOps team also adds Executive Strategy Alignment to the roadmap, so that the multi-year plan for the AI tagging capability is decided with cost and value data in front of leaders.

What the example teaches

Kestrel did not try to do everything. It started with data and allocation (Inform), built trust with showback and fast anomaly alerts, used Scopes and unit metrics to answer the questions leadership actually had, sequenced optimisation sensibly, made improvements stick through automation and policy, and used assessment to choose the next priorities. Different capabilities ended up at different maturity levels, which is normal and intended.

Lesson 7 – Relationship to other standards and frameworks

FinOps does not exist alone. The 2026 update gives particular attention to intersecting disciplines whose people are the allied personas. Understanding the boundaries helps you avoid duplicated work and turf disputes.

Framework or discipline	Main focus	How it relates to FinOps
IT financial management (ITFM), often using the Technology Business Management (TBM) taxonomy	Planning, accounting and reporting of all IT spending and linking it to business services	Overlaps strongly with Quantify Business Value; ITFM tends to work on longer cycles and the whole IT budget, FinOps adds near-real-time engineering collaboration. Aligning taxonomies avoids two different versions of the truth.
IT asset management (ITAM), including ISO/IEC 19770 software asset management	Inventory, licence entitlement and compliance for hardware and software assets	Shares the Licensing & SaaS capability; ITAM knows entitlements and contract terms, FinOps knows consumption and cost. Together they decide on renewals and bring-your-own-licence options.
IT service management (ITSM), for example ITIL 4 or ISO/IEC 20000-1	Designing, delivering and supporting IT services to agreed service levels	Service catalogues and service levels give the context for cost trade-offs; change management can include cost review; FinOps data helps price services.
FOCUS (FinOps Open Cost and Usage Specification)	A common format and meaning for billing data across vendors	Supports the Data Ingestion capability and the technology category pages; it is a data specification, not an operating model.
Cloud provider guidance such as the cost optimisation pillar of the AWS Well-Architected Framework or Microsoft's FinOps guidance for Azure	Provider-specific design and cost practices	Useful detail for the Optimize phase on one platform; FinOps adds cross-provider, cross-persona governance and value measurement.
COBIT and ISO/IEC 38500 (governance of IT)	Board-level governance and management objectives for enterprise IT	Provide the governance context; FinOps can be one of the practices that delivers value and resource optimisation objectives.
Sustainability and carbon accounting	Measuring and reducing the environmental impact of technology	Shares data and allocation methods; the Sustainability capability brings carbon into the same decisions as cost.

Choosing and combining

Most organisations do not choose FinOps instead of these frameworks; they combine them. A practical rule is to let each discipline lead where it is strongest. ITAM leads on entitlements and licence compliance, ITFM on enterprise budgeting and cost models, ITSM on service definitions and change control, Security on access and threat response, and FinOps on usage-based cost data, allocation, unit economics and the day-to-day collaboration between engineers and finance. The Intersecting Disciplines capability exists to agree these boundaries explicitly, for example through a shared data model, joint reviews of large renewals and clear ownership of each KPI.

FinOps also complements DevOps and platform engineering. Cost is treated as another non-functional requirement alongside performance, reliability and security. When cost data is available in the same tools engineers use for deployments and monitoring, cost-aware design becomes part of normal engineering rather than an occasional audit.

Common pitfalls and best practices

Common pitfalls

Treating FinOps as cost cutting. Chasing the smallest possible bill damages reliability and innovation and makes engineers see FinOps as an enemy. The aim is value, measured with unit economics.
Buying a tool and calling it FinOps. Dashboards nobody reads change nothing. Without ownership, cadence and collaboration, a tool only produces reports.
Centralising all optimisation. A central team that tries to rightsize every resource becomes a bottleneck and removes accountability from the teams that actually control usage.
Committing before cleaning up. Buying large commitment discounts before removing waste and rightsizing can lock in payments for capacity that is not needed.
Waiting for perfect data. Teams that refuse to report until tagging is perfect never start. Begin with account structure and good-enough allocation, then improve.
Jumping to chargeback too early. Charging budgets with numbers that teams consider unfair destroys trust; showback first builds agreement on the allocation rules.
Aiming for Run everywhere. Maturing every capability to the highest level wastes effort on areas that bring little value.
Forgetting non-cloud spending. Managing cloud carefully while SaaS, licences and AI services grow unchecked leaves large parts of technology spending outside the practice.

Best practices

Secure executive sponsorship from both technology and finance leadership, with a clear statement of why FinOps matters.
Make data timely, accessible and persona-specific, so each group sees the cost information it can act on, in the tools it already uses.
Push accountability to the edge: the team that consumes a resource owns its cost, supported by champions and a central enablement team.
Define unit metrics with product owners early, so that growth and efficiency can be told apart.
Sequence optimisation: remove waste and rightsize, then commit for the stable baseline, and review coverage and utilisation regularly.
Automate guardrails such as tagging policies, budget alerts, schedules and anomaly routing, so improvements persist without constant manual effort.
Assess focused and often, using the five lenses on a small set of capabilities and target groups, and set targets based on business value.
Coordinate with intersecting disciplines such as ITAM, ITFM, Security and Sustainability, using shared data such as FOCUS-formatted billing data.

Summary and key takeaways

FinOps is an operational framework and cultural practice that helps organisations maximise the business value of technology through collaboration, timely data and shared accountability.
The Framework is maintained by the FinOps Foundation under the Linux Foundation and updated in place; the current version is the 2026 update, and it now covers cloud, SaaS, data centre, data platforms, AI and other technology spending.
Six principles stress collaboration, value-driven decisions, ownership of usage, accessible and timely data, central enablement and using variable pricing to advantage.
Core personas (FinOps Practitioner, Engineering, Finance, Product, Procurement, Leadership) practise FinOps; allied personas (ITAM, ITFM, ITSM, Security, Sustainability) coordinate with it.
Work cycles through Inform, Optimize and Operate continuously, and each capability matures through Crawl, Walk and Run according to business value, not as an end in itself.
Twenty-two capabilities sit in four domains: Understand Usage & Cost, Quantify Business Value, Optimize Usage & Cost and Manage the FinOps Practice; Scopes apply them to segments of spend that matter to the business.
There is no compliance certificate for organisations; maturity is self-assessed with five lenses scored 0–4, while certifications exist for individuals and for tool and service vendors.
FinOps works best combined with ITFM, ITAM, ITSM, security and sustainability practices, using common data such as FOCUS.

Reflection questions

Think of a technology cost in your organisation that nobody clearly owns. How would you allocate it, and which persona would need to agree to the rule?
Choose one product or service you know. What unit metric would best show whether its technology spending is becoming more efficient, and where would the data for the denominator come from?
If you had to define two Scopes for your organisation next quarter, what business questions would they answer and which technology categories would each one span?
Pick two capabilities and estimate their maturity in your organisation using the five assessment lenses. Where would a score of around 12 out of 20 be good enough, and where would you aim higher?
Your finance team wants to introduce chargeback immediately, while engineering leaders say the data is not trusted. How would you plan the transition, and what evidence would show that you are ready?