The first time somebody hands you the FinOps Framework poster, the honest reaction is that it looks like an org chart drawn by a committee. Six principles, eleven personas, four domains, twenty two capabilities, three phases, three maturity levels, and now Scopes and Technology Categories on top. It is a lot of boxes for a discipline whose entire job is to stop people wasting money.

The reason the poster looks heavy is that it is trying to describe every organisation at once, from a five person startup to a bank with nine cloud accounts per business unit. Read as a to do list it is paralysing. Read as a vocabulary, it becomes the most useful thing in the discipline, because it lets you say precisely which part of the problem you are working on and who needs to be in the room. That reframing is the whole point of this part.

What the Framework actually is

The FinOps Foundation, the Linux Foundation project that maintains all of this, publishes the Framework under a Creative Commons licence and describes it as the operating model for establishing and excelling in the practice of FinOps. Two words in that sentence matter. Operating, because it describes how you run something continuously rather than how you deliver a project. And practice, because it assumes people, habits and negotiation rather than a tool you install.

The Foundation is direct about how to use it: the Framework is flexible and non prescriptive, with components practitioners select from, so that organisations can start where the greatest need is. That is an unusual thing for a framework to say about itself, and it is the sentence most people skip. It means there is no certified correct order, no mandatory sequence, and no failure condition for skipping a box. It also means nobody is going to tell you where to start, which is why so many practices stall in month two.

The current definition, updated for the 2026 revision to align with the Foundation mission, reads that 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. Note the word technology rather than cloud. That change is recent and it is not cosmetic, which I come back to when I cover Scopes below.

Structurally, the pieces stack. Principles sit at the top as the reasoning. Scopes and Technology Categories define what slice of spend you are talking about. Personas define who is involved. Domains define the outcomes you are chasing, and Capabilities are the concrete activities that produce them. Phases describe the rhythm you run all of it in, and the Maturity model describes how good you currently are at any single piece. Once you can locate a conversation on that stack, cost meetings get dramatically shorter.

Six principles, and what each one costs you

The Foundation describes the Principles as a north star, in no particular order, all of them important. That framing undersells them. In practice the Principles are the arguments you deploy when somebody senior objects to something you are trying to do, and each one has a cost attached that nobody mentions when they are printed on a slide.

Take the principle that everyone takes ownership for their technology usage. Read casually it is motivational filler. Read properly it says accountability is pushed to the edge, engineers own cost from architecture design through to ongoing operations, and cost is treated as a first class metric from the beginning of the software development lifecycle. That is a real demand on engineering time, and it will be resisted by anyone whose performance is measured purely on delivery velocity. If you cannot get that resistance resolved, no dashboard you build will change behaviour.

Or take the principle that FinOps should be enabled centrally. The Foundation is specific that rate, commitment and discount optimisation are best centralised, so that economies of scale apply and engineers can stay focused on optimising their usage. That is the quantity versus rate split from Part 2, promoted to an organisational design rule. It also means the central team has to earn its position rather than simply police spend, and the fastest way to fail is to centralise the reporting while leaving the decisions distributed.

The principle I see misapplied most often is the one about taking advantage of the variable cost model. Teams quote it to justify moving to cloud and then never exercise the option, which is the failure mode I described in Part 2. The Foundation now words this principle across technology categories, noting that each category, public cloud, data centre, SaaS, licences, data platforms, carries cost models with pros and cons, and that the lessons learned managing cloud should be applied elsewhere. That is a much stronger claim than it appears.

Principle wording paraphrased from the FinOps Foundation Principles page, July 2026. The cost column is my own assessment from running these conversations, not Foundation content.

Who is in the room

Personas are the Framework element that new practitioners skip and experienced ones rely on most. The Foundation splits them into Core Personas, always engaged in a FinOps practice, and Allied Personas, which support it. The six Core Personas are FinOps Practitioner, Engineering, Finance, Leadership, Procurement and Product. The Allied Personas are ITAM, ITFM, ITSM, Security and Sustainability.

Three of those acronyms are worth defining now because they turn up constantly in enterprise settings. ITAM is IT Asset Management, the function tracking the contractual value and lifecycle of hardware and software you own. ITFM is IT Financial Management, which handles how technology investment gets reported and charged back to the general ledger. ITSM is IT Service Management, the operational discipline covering incidents, changes and service catalogues.

The practical value of the persona list is that it turns a vague complaint into a routing decision. If your finding is that a service is oversized, the persona is Engineering and the conversation is technical. If your finding is that commitment coverage dropped, the persona is Procurement plus Leadership and the conversation is commercial. If your finding is that nobody can tell which team owns a cost centre, the persona is Finance and the conversation is about allocation structure. Same dataset, three different rooms, and picking the wrong one wastes a fortnight.

Product being a Core Persona is the part that surprises people, and I think it is the most important recent addition. Product owns the business denominator that unit economics needs, the one I flagged at the end of Part 2. Without Product in the room, cost per customer is a number the finance team invented, and engineering will treat it accordingly.

flowchart LR
  A[Inform: ingest, allocate, report] --> B{Is the data trusted}
  B -->|No| A
  B -->|Yes| C[Optimize: list rate and usage options]
  C --> D{Which options fit the business goal}
  D -->|Backlog| C
  D -->|Selected| E[Operate: act, automate, govern]
  E --> F[Measure the effect]
  F --> A

Inform, Optimize, Operate

These three phases are the most quoted part of the Framework and the most misread. They look like a project plan, so people run them like one: a discovery phase, then an optimisation project, then handover to business as usual. That is close to the opposite of what the Foundation describes.

Inform is visibility and allocation. You examine cost, usage and efficiency data, using capabilities like Data Ingestion, Allocation, Reporting and Analytics, Forecasting and Unit Economics, so that spend can be accurately attributed and benchmarked. The Foundation makes a point that stands out: because cloud, SaaS and AI pricing keeps changing, you have to continuously revisit Inform to validate that optimisation actions had the effect you claimed. Inform is not a stage you complete. It is the phase you keep returning to in order to prove your own results.

Optimize is rates and usage. Here you identify options rather than execute them, which is a distinction worth holding onto. Usage optimisation means using fewer resources to reach an acceptable outcome and needs engineering collaboration. Rate optimisation means paying an appropriate amount for resources you genuinely need and requires procurement and leadership. The output of this phase is a prioritised list with a documented rationale, plus a backlog of everything that did not make the cut. Options will compete, and the Foundation is explicit that you need agreed criteria to choose between them rather than deciding case by case.

Operate is where changes get made and habits get built. Crucially, the Foundation notes that some Operate actions are not usage or rate adjustments at all: they are improvements to the practice itself, maturing a capability or evolving how FinOps runs in your organisation. That single sentence gives you permission to spend a cycle fixing your tagging pipeline instead of chasing another idle instance, and it is the permission most practices need.

Domains and capabilities

Domains are the outcomes a FinOps practice should deliver, and Capabilities describe how to achieve them. There are four Domains and, as of the 2026 Framework, twenty two Capabilities distributed across them. The distribution itself tells you something the poster does not spell out.

Understand Usage and Cost holds four capabilities: Data Ingestion, Allocation, Reporting and Analytics, and Anomaly Management. Quantify Business Value holds five: Planning and Estimating, Forecasting, Budgeting, KPIs and Benchmarking, and Unit Economics. Optimize Usage and Cost holds five: Architecting and Workload Placement, Usage Optimization, Rate Optimization, Licensing and SaaS, and Sustainability. Manage the FinOps Practice holds eight: Executive Strategy Alignment, FinOps Practice Operations, Governance Policy and Risk, FinOps Education and Enablement, Invoicing and Chargeback, FinOps Assessment, Automation Tools and Services, and Intersecting Disciplines.

Look at that shape. The largest single Domain is the one about running the practice, not the one about saving money. That is the Framework quietly telling you where the difficulty lives. Optimisation techniques are largely a solved problem with plenty of tooling. Sustaining an operating model that keeps applying them, across teams that do not report to you, through reorganisations and leadership changes, is not. If you are choosing where to invest your own learning time, that eight to five ratio is a fair guide.

Domain and capability counts from the FinOps Framework overview, July 2026. Part mapping is my own plan for this series, not Foundation content.

Scopes and technology categories

Two elements were added recently and they change how the rest of the Framework is applied, so it is worth getting them straight even though they sound abstract. A FinOps Scope, introduced in the 2025 Framework and refined in 2026, is a defined segment of spending across technology categories, aligned to business constructs such as products, cost centres or environments, that guides how FinOps is applied to maximise technology value. A Technology Category is the kind of spend itself: Public Cloud, SaaS, Data Center, Data Cloud Platforms, AI.

The Foundation puts the distinction in one line that is worth memorising: the Technology Category is the what, and the Scope is the why. A Scope is a decision context. It determines which Personas get engaged, which Capabilities you apply, and what counts as success. Your AI initiative might accept high waste in exchange for speed, while your billing platform accepts none, and both can be running on the same cloud account.

The 2026 guidance adds something I think practitioners underuse: Scopes are initiated in response to business questions, usually from Leadership, not because a practitioner finds an area of spend interesting. They are also situational, flexing in duration and intensity, and the guidance encourages you to recognise when a Scope has served its purpose and can be wound down or absorbed. Cost programmes accumulate workstreams that nobody has the authority to stop, and this is the Framework handing you that authority.

One more 2026 change worth knowing about now. Executive Strategy Alignment was added as a new Capability in the Manage the FinOps Practice Domain, organised around Executive Priority Alignment, Multi Year Investment Strategy, Facilitate Product Prioritization Strategy, and Enable Strategic Decision Support. The Foundation describes the shift as moving up rather than only shifting left, meaning FinOps engages where investment strategy is shaped, not only earlier in the delivery lifecycle. Whether your organisation is ready for that is a separate question, but the vocabulary now exists.

flowchart TD
  A[Leadership asks a business question] --> B[Draw out the real outcome wanted]
  B --> C[Define a FinOps Scope]
  C --> D[Which technology categories are in it]
  C --> E[Which personas must be engaged]
  C --> F[Which capabilities apply and at what maturity]
  D --> G[Run Inform, Optimize, Operate at the agreed cadence]
  E --> G
  F --> G
  G --> H{Has the Scope served its purpose}
  H -->|No| G
  H -->|Yes| I[Wind down or absorb into standing practice]

Crawl, walk, run

The Maturity model is three levels, Crawl, Walk and Run, and its most useful property is that it applies per Capability rather than to your practice as a whole. There is no such thing as a Walk level FinOps team. There is a team that is at Run on Allocation, Walk on Anomaly Management and has not started Unit Economics, which is a far more actionable statement.

The Foundation frames the approach as starting small and growing in scale, scope and complexity as business value warrants. That last clause is the one that gives you cover to leave a capability at Crawl permanently. If nobody in your organisation makes a decision using carbon data, Sustainability stays at Crawl and you spend the effort somewhere it changes an outcome. Maturity is not a score to maximise.

What Crawl, Walk and Run mean concretely varies by capability, and the Foundation publishes maturity guidance on each capability page rather than as one global definition. The table below is how I describe the levels to teams for Allocation specifically, which is the capability almost everyone starts with and the subject of Part 5.

Crawl, Walk and Run are FinOps Foundation terms. The thresholds and timings in this table are my own working definitions for Allocation, offered as a starting point rather than a Foundation standard. Part 5 covers tagging and allocation in full.

Pick three capabilities and complete one loop this month

Here is the recommendation, and it is deliberately small. Choose three Capabilities, not twenty two. Get each to Crawl, and run one complete pass through Inform, Optimize and Operate inside a single month. For almost every organisation starting out, the right three are Allocation, Reporting and Analytics, and Rate Optimization, because together they let you answer whose cost this is, show it to that person, and bank one commercial saving that funds the next quarter of work.

The reason to insist on completing the loop rather than perfecting the first phase is that the loop is what generates credibility, and credibility is the actual constraint on a FinOps practice. Nobody grants a central team influence over architecture decisions on the strength of a dashboard. They grant it after that team produced a number somebody trusted and a saving somebody could verify. Breadth across capabilities looks impressive in a maturity assessment and changes nothing in the bill.

Part 4 takes the next step down into detail, reading the cloud bill itself, and works through the anatomy of an AWS, Azure and GCP invoice so that the Inform phase has something concrete underneath it. It builds directly on the quantity and rate split from Part 2 and the Understand Usage and Cost Domain described here. The full sequence lives on the Cloud FinOps guide.

Before you read on, write down the three Capabilities you are going to take to Crawl, and the date you will have completed one full loop. If you cannot name three, that is the finding.

References

• FinOps Framework Overview, FinOps Foundation
• FinOps Principles, FinOps Foundation
• FinOps Phases, Inform Optimize Operate, FinOps Foundation
• FinOps Framework 2026 Updates, FinOps Foundation
• FinOps Scopes, FinOps Foundation

FinOps Framework content is published by the FinOps Foundation under CC BY 4.0 and is paraphrased here with attribution.

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts