The FinOps Foundation's silence on private cloud is no longer sustainable.

The Framework grew up. The examples did not.

The 2026 FinOps Framework is a serious, overdue piece of work. It retires cloud-specific verbs in favor of technology-inclusive ones, reorganizes capabilities around Scopes that practitioners define, and openly acknowledges that FinOps is no longer a thing one does to an AWS bill. The language is right. The intent is right. And if you read nothing but the capability pages, you would come away believing private cloud is a first-class citizen of the discipline.

Then you try to actually apply it to a data hall you own, or a government tenant running in a sovereign region, or a colocation cage across three carriers. The framework tells you to tag resources. Your firmware does not tag resources. It tells you to pull allocation from a billing feed. Your allocation comes from an environmental-monitoring system, a rack-space inventory in a CMDB, and a spreadsheet maintained by the person who manages your carrier invoices.

The Scopes mechanism is correct. The scaffolding underneath it is still shaped like a public-cloud account.

Why private cloud keeps falling through the gap

Three forces combine to keep the Framework's center of gravity in public cloud.

First, the data shape. Public cloud exposes fine-grained, near-real-time billing with programmatic access. Private cloud exposes monthly power draw, quarterly depreciation, and occasionally a CMDB. The Framework's capability definitions presume the former and offer accommodations for the latter. Accommodations are not parity.

Second, the tooling economy. Vendors sell to the venue with the biggest surface area. The certified-provider ecosystem around the Foundation is overwhelmingly shaped to integrate with AWS, Azure, and GCP. A tool that ingests a monthly colo invoice and allocates against kW draw is a narrower market and a harder product.

Third, the practitioner gravity. The loudest voices in the community are practitioners at companies where public cloud is the dominant cost. That bias is not a conspiracy; it is just math. But it means the case studies, the working groups, and the conference keynotes skew toward the estate that is most visible rather than the estate that is most expensive.

The 57% number and what it should trigger

The State of FinOps 2026 reports that roughly 57% of FinOps teams now manage private cloud as part of their mandate. That should be the moment a community pivots. If a majority of its practitioners operate in a domain, the reference implementation of the discipline has to reflect that domain at comparable fidelity. Today, a search of the Foundation's published examples for "colocation" returns a fraction of the artifacts available for "Transit Gateway."

This is not an indictment of the people doing the work. The Framework team is small, the Scopes restructuring is nontrivial, and the 2026 release is the right direction of travel. It is a request to pick up the pace. The gap between "private cloud is a Scope" and "here is how to implement private-cloud allocation to the fidelity a CFO will accept" is the gap hybrid operators live in every day.

What is actually missing

Four concrete artifacts would close most of the gap.

One: capability bindings per Scope. A capability like Allocation is currently defined abstractly, with a public-cloud implementation implicit in the examples. Each Scope needs an explicit binding — here are the data sources you use in a private-cloud Scope, here is the allocation grain, here is the expected cadence, here is the fidelity you can reasonably achieve. Without bindings, practitioners invent their own, which is how you end up with forty variants of "power allocated by rack density."

Two: shared allocation primitives. Public cloud has instance-hours, request-counts, and service-linked charges. Private cloud has kW-months, rack-unit-months, cross-connect-months, bandwidth-95th-percentile-Mbps, and depreciation-months on a defined schedule. These primitives exist in practice at every colo operator and many sovereign providers. They need to be written down, versioned, and referenced the way public-cloud units are.

Three: a maturity rubric that does not presuppose an API. The Framework's maturity questions lean on concepts like "real-time anomaly detection" and "automated rightsizing" that do not translate cleanly to a kit that reports draw every fifteen minutes to a DCIM. A Crawl/Walk/Run rubric for private cloud should name the artifacts that exist there — a power-density map, a capacity-commit-to-actual reconciliation, a refresh-cycle depreciation schedule — rather than asking operators to explain why they do not have Cost Explorer.

Four: worked examples at AWS Transit Gateway fidelity. The Transit Gateway chargeback example is, bluntly, the best single artifact the Foundation ecosystem has ever produced. It names a shared resource, names a metering source, names a joining strategy, and walks through the math. Private cloud has no equivalent. A community-owned worked example — say, "allocating a shared power-and-cooling bill across three business units in a colo cage using DCIM draw plus a fairness-weighted idle overhead" — would do more for adoption than any number of capability updates.

Sovereign is the next wave, and nobody is publishing for it

Public cloud FinOps is a solved enough problem that the center of activity is moving. Sovereign-cloud tenants, regulated private regions, and on-prem estates operated for residency or latency reasons are growing fast, and they inherit the hardest parts of both worlds. They have cloud-like elasticity at the VM layer and colo-like opacity at the facility layer. They often run on a public hyperscaler's software with pricing models that do not match the public list, contractual constraints that prohibit certain data flows, and commit structures negotiated at the national-authority level.

None of this is exotic. It is everyday reality for European banks, US federal tenants, and a growing cohort of Asian enterprises. And it is almost entirely absent from the Foundation's published examples. The practitioner in a sovereign tenant today is improvising against a framework whose exemplars are someone else's venue. That is fixable, and the community should fix it before vendors do it for us with proprietary glossaries.

What a serious next step looks like

The Foundation does not need to rewrite the Framework. It needs to ship a second volume — a reference artifact library organized by Scope, with each Scope given the same fidelity the public-cloud examples have enjoyed for four years.

• A private-cloud chargeback example at Transit-Gateway fidelity.
• A sovereign-tenant allocation example that addresses contractual constraints, not just technical ones.
• A colocation-plus-cloud bandwidth allocation pattern that reconciles 95th-percentile carrier bills with cloud egress charges.
• A SaaS-licensing allocation pattern that handles pooled seats and per-feature metering.
• An AI-infrastructure allocation pattern that sits cleanly across training on-prem and inference on public cloud.

Five reference implementations, each roughly the length and ambition of the Transit Gateway piece, would move the practice forward more than any number of capability-page edits. They would also give the broader Framework real teeth in venues where the abstract guidance currently floats.

The ask

The 2026 Framework is, again, a good faith effort and the right direction. The critique here is not that the Foundation has failed to address private cloud. It is that the work is half-done, and the second half is the part practitioners actually need to do their jobs. Scopes is the scaffolding. The reference library is the building.

Until the reference library exists at parity for every Scope we claim to support, "hybrid FinOps" is a slide deck. The community can do better than that — and given how much of the practice already lives outside the public-cloud account, we have to.