The FinOps Foundation Framework: A Practitioner's Walkthrough

The FinOps Foundation Framework is the reference architecture for cloud financial management. It’s been maintained by the FinOps Foundation (a Linux Foundation project) since 2018 and has matured into the de facto standard most serious cloud cost work is built on. In 2026 it received a substantial refresh that extended its scope from pure cloud spend to include AI/ML, SaaS, licensing, and broader technology categories.

For practitioners thinking about formalising FinOps practice — or evaluating providers who claim to do FinOps — knowing what the Framework actually covers is what separates a real implementation from a marketing label. This post walks through the Framework structure, the 2026 updates, and how it applies specifically to AI/ML spend.

I’m Ravi. I run three production AI SaaS solo (Prism, Citare, BatchWise) and do advisory work on FinOps via rikuq services. The walkthrough below is what I use when teams ask “what does the FinOps Foundation Framework actually look like in practice?”

TL;DR

Element	What it is
Phases	Three concurrent operational modes: Inform, Optimize, Operate
Principles	Six foundational principles guiding all FinOps practice
Capabilities	The functional areas of activity a FinOps practice covers
Personas	Engineering, Finance, Procurement, Leadership, Operations, ITAM, Sustainability
2026 additions	Executive Strategy Alignment, Technology Categories taxonomy, Converging Disciplines recognition
AI/ML extension	New Technology Category with specifics on GPU/CPU differential, token pricing, make-vs-buy economics

The six foundational principles

Before the structural mechanics, the Framework’s six principles establish the cultural and operational mindset. They’re worth knowing because they’re how the Framework’s authors test whether something is “really” FinOps or just cloud cost cutting.

1. Teams need to collaborate. Engineering, Finance, Procurement, and Business teams work together as one. FinOps isn’t a finance discipline that engineering tolerates; it’s a shared practice.
2. Decisions are driven by business value of cloud. Optimising for cost without optimising for value is not FinOps. Increasing spend to capture disproportionate value is correct.
3. Everyone takes ownership for their cloud usage. Engineers see the cost of what they consume; that visibility creates accountability without policing.
4. FinOps reports should be accessible and timely. Cost data must be available to decision-makers in the timeframe their decisions operate on — not monthly summary, daily or near-real-time at the resource level.
5. A centralised team drives FinOps. Not every team builds its own practice; a small central team owns the framework and supports the distributed adopters.
6. Take advantage of the variable cost model of the cloud. Use the elasticity, the reserved-capacity options, the spot pricing. Don’t treat cloud as fixed infrastructure with a different billing portal.

These principles read as obvious in 2026 but they were genuinely new in 2018. They’re also the test for whether a vendor or consultant claiming to do FinOps actually does — if their pitch is “we’ll reduce your cloud bill,” they’re missing principle 2.

The three phases — Inform, Optimize, Operate

The Framework’s structural backbone. Three concurrent operational modes:

Phase	Purpose	Core activities
Inform	Deliver cost visibility; create shared accountability	Cost allocation, benchmarking, budgeting, forecasting, anomaly detection
Optimize	Reduce waste; improve efficiency per unit of business value	Reserved capacity / committed-use discounts, right-sizing, vendor consolidation, workload routing
Operate	Enforce governance; track KPIs; automate guardrails	Policy automation, alerts on anomalies, FinOps-as-code, executive reporting

Different team members work in different phases simultaneously. Engineering typically operates in Optimize. Finance typically operates in Inform. Leadership typically operates in Operate. The phases describe types of activity, not time-ordered gates.

This concurrency matters because the most common implementation mistake is treating Inform as “phase 1” that must complete before Optimize starts. That produces a year of building dashboards without ever taking action. A mature FinOps practice has all three running continuously, with explicit hand-offs between teams.

What “Inform” actually involves

Cost visibility at the granularity decisions are actually made at. For most modern organisations:

• Cost allocation by team / product / feature / cost-centre, with the allocation method documented and consistent
• Benchmarking against internal historical baselines and external comparable workloads (where possible)
• Budgeting and forecasting at a granularity that maps to operational decisions (monthly per team, not just annual aggregate)
• Anomaly detection on consumption — alerts when actual spend deviates from forecast by more than a threshold
• Showback (visibility without enforcement) and chargeback (visibility with enforcement) mechanics

The Inform phase output is data that drives decisions. If your Inform output is a beautiful dashboard nobody acts on, the phase isn’t done — it’s stuck.

What “Optimize” actually involves

Reducing cost per unit of business value, not aggregate cost. Specific activities:

• Reserved capacity / committed-use discount analysis and execution (typically 30-50% savings vs on-demand for stable workloads)
• Right-sizing — matching instance types to actual workload requirements rather than over-provisioning for peak
• Workload routing — moving workloads to lower-cost regions, lower-cost compute types (CPU vs GPU), or lower-cost providers where the trade-off doesn’t compromise value
• Vendor consolidation — reducing redundancy in tooling, AI providers, SaaS subscriptions
• Architecture optimisation — caching, batching, sub-agent discipline for AI workloads, prompt engineering for cost

For AI workloads specifically, Optimize work concentrates on model selection economics (which model for which workload), prompt caching (60-90% cost reduction on cacheable input), and retry hygiene (preventing silent cost spikes from broken retry loops).

What “Operate” actually involves

Building the operating model so optimisations sustain over time without continuous re-discovery. Specific activities:

• Policy automation — guardrails that prevent re-emergence of fixed cost issues (e.g., auto-tag enforcement, instance-type whitelists)
• Anomaly alerts that fire to the engineering team that owns the spend, not just to finance
• FinOps-as-code — defining cost policies, allocation rules, and budgets as version-controlled artifacts
• Executive reporting that connects technology investment to business outcomes
• Continuous improvement cadence (quarterly retrospectives, capability maturation)

The Operate phase is where most FinOps practices fail at maturation. The work to set up the practice often runs ahead of the work to make the practice sustainable, and without sustained operations the optimisations decay within 6-12 months.

Capabilities — the functional areas of activity

Within the three phases, the Framework defines specific Capabilities that group related work. The 2026 refresh structures these into four main domains:

Understand Cloud Usage and Cost

• Data ingestion and normalisation
• Allocation
• Reporting and analytics
• Anomaly management

Quantify Business Value

• Forecasting
• Budgeting
• Benchmarking
• Unit economics

Optimize Cloud Usage and Cost

• Rate optimisation (reserved capacity, savings plans, committed-use)
• Usage optimisation (right-sizing, workload management, sustainability)
• Architecting for the cloud (FinOps-aware architecture decisions)

Manage the FinOps Practice

• FinOps practice operations
• Cloud policy and governance
• FinOps education and enablement
• Onboarding workloads
• Executive Strategy Alignment (new in 2026)

Each Capability has its own maturity model (Crawl / Walk / Run) that lets teams assess where they are and prioritise next investments. This granularity is what makes the Framework operationally useful rather than just conceptually elegant.

Personas — who actually does the work

The Framework recognises that FinOps practice involves multiple roles working together. The recognised Personas:

• FinOps Practitioner — the dedicated FinOps role, often in a small central team
• Engineering — the consumers and operational decision-makers on cloud usage
• Finance — owns budget, accounting, and financial reporting
• Procurement — owns vendor relationships, contracts, and commitment management
• Leadership — accountable for strategic technology investment decisions
• Operations — runs the infrastructure the FinOps practice optimises
• ITAM — adjacent discipline tracking assets and licences
• Sustainability — adjacent discipline for emissions-aware optimisation

Each Persona contributes specific perspectives to each Capability. The 2026 framework’s emphasis on Executive Strategy Alignment connects the Leadership Persona to all Capabilities more explicitly than the 2024 version did.

The 2026 Framework updates in detail

The 2026 refresh introduced three material changes worth understanding individually.

1. Executive Strategy Alignment

A new core Capability under “Manage the FinOps Practice.” Recognises that FinOps in 2026 operates as a strategic partner to executive leadership, not just an optimisation function. Connects technology investment to business outcomes, supports multi-year planning, and enables informed trade-offs across the technology estate.

In practice this means the FinOps practice’s executive reporting must answer questions like: “if we doubled our AI investment over the next 18 months, what business value would compound, and what would the operational risks be?” — not just “here’s our cloud bill broken down by team.”

2. Technology Categories taxonomy

A refreshed taxonomy that distinguishes:

• Cloud (compute, storage, network, data, application services)
• SaaS (subscription software)
• Licensing (perpetual and term licenses)
• Data centre (on-premises infrastructure)
• AI/ML (foundation model APIs, fine-tuning, inference, training)
• Other technology spend

Allows consistent FinOps practice across the full technology cost base — important because many organisations have mature cloud FinOps but immature SaaS / AI / licensing practice. The taxonomy is what lets the same Capabilities apply across all categories without separate frameworks for each.

3. Converging Disciplines

Explicit recognition that FinOps converges with adjacent disciplines:

• GreenOps — carbon-aware cost optimisation; FinOps with sustainability overlay
• AIOps — AI-driven operations and infrastructure management; converges with FinOps as AI itself becomes a major spend category
• DevSecOps — security cost optimisation; ensuring security investments are FinOps-aware
• ITAM — IT asset management; specifically licences and contracts that FinOps consumption data informs

The convergence recognition isn’t just labels — it’s the framework acknowledging that a mature 2026 organisation runs all these disciplines with shared data infrastructure rather than as siloed practices.

FinOps applied to AI/ML spend specifically

The 2026 framework explicitly extends FinOps practice to AI/ML platform spend. AI is structurally different from traditional cloud spend optimisation in three ways:

15x cost differential between GPU and CPU compute. Model + provider + instance type decisions carry materially more financial impact than equivalent decisions in traditional cloud workloads. A bad GPU sizing decision can cost 15x what an equivalent CPU sizing decision would. Inform and Optimize phases need to surface this differential at the decision granularity where it gets made.

Foundation model API consumption pricing. Per-token, per-call, per-image rather than per-hour-per-instance. Requires different cost allocation logic. Standard cloud FinOps tools that allocate based on resource consumption don’t model token-based pricing well. Either the gateway layer does attribution natively (see why LLM gateway attribution is harder than cloud FinOps) or you wrap existing tools with custom dashboards.

Make-vs-buy economics on AI platforms. Fine-tuning vs API consumption vs in-house foundation model development each have distinct unit economics that aren’t substitutes. The Optimize phase work involves choosing between these architectures at the workload level, not just optimising whichever you’ve picked.

For Indian companies the AI extension matters especially because AI spend is growing 80%+ year-over-year per NASSCOM (2026) while traditional cloud FinOps maturity remains uneven. The opportunity is to skip a generation of cloud-only FinOps and build AI-aware practice directly.

India context — adoption stage and trajectory

FinOps practice in Indian enterprises is at an earlier maturity stage than US / EU peers. Per NASSCOM 2026 data, 67% of Indian enterprises allocate less than 10% of IT budget to AI — but that figure is rising at 25-35% CAGR. This means Indian CFOs face two distinct challenges:

• Traditional cloud cost management discipline is still maturing in many Indian mid-market companies (Inform + Optimize work largely incomplete)
• AI spend layer is growing on top of that incomplete foundation

The result: AI spend tends to compound existing cloud cost discipline gaps rather than benefiting from a mature FinOps baseline. The pragmatic sequencing for Indian mid-market entities:

1. Establish FinOps Inform-phase visibility on AI/cloud spend first (highest ROI starting point)
2. Layer Optimize work on the highest-leverage AI workloads (model selection, prompt caching, retry hygiene)
3. Build Operate-phase discipline once Optimize wins demonstrate the practice’s value
4. Add ITFM and ITAM disciplines on top (see FinOps vs ITFM vs ITAM for sequencing detail)

Certifications worth knowing about

The FinOps Foundation runs two practitioner certifications that are increasingly recognised:

• FinOps Certified Practitioner (FOCP) — broad FinOps practice certification covering the full Framework
• FinOps Certified Engineer (FOCE) — engineering-focused certification on FinOps-aware architecture and tooling

For organisations hiring FinOps roles, either certification is a useful signal of formal training. The FOCP exam is structured around the Framework’s Capabilities and is updated each time the Framework refreshes.

How to actually adopt the Framework

If you’re starting from scratch with no formal FinOps practice:

Week 1-2: Inform baseline. Use hyperscaler-native tools (AWS Cost Explorer + CUR, Azure Cost Management, GCP Billing Reports) to establish cost visibility by team / product / environment. Output: a dashboard the engineering teams actually look at weekly.

Week 3-4: First Optimize pass. Pick the 2-3 highest-leverage optimisations from the baseline (reserved capacity, model substitution for AI workloads, idle resource elimination). Execute them. Measure the impact. This is where most FinOps efforts that stalled get re-started — visible early wins justify the practice.

Week 5-8: Operate setup. Build the anomaly alerts, automate the policies that prevent regression, set the executive reporting cadence. Hand off ongoing operations to the engineering teams; the FinOps Practitioner role becomes a coach rather than the doer.

Month 3-6: Maturation. Run the Capability maturity assessment, identify priority gaps, run quarterly retrospectives. Build the muscle.

If you want a written scope proposal for what an external diagnostic or implementation support would look like for your specific situation, the services page has both a Cal.com booking link and a Tally intake form.

What’s next

This post is the Framework walkthrough. The adjacent posts that go deeper on specific dimensions:

• What is LLM FinOps? — the broader discipline this Framework structures
• FinOps vs ITFM vs ITAM — where this Framework sits relative to adjacent disciplines
• AI Systems Review framework — how to apply the Framework to AI/ML spend at Indian mid-market scale
• Why LLM gateway attribution is harder than cloud FinOps ever was — the attribution challenge specific to AI spend