A FinOps scope is the part of technology spend a practice deliberately applies FinOps to; in the FinOps Foundation's Framework, licensed CC BY 4.0, it is cut along business lines such as a product, cost centre or environment and may span several technology categories. The scope sets which spend the practice covers and how intensively; the technology category says what kind of technology it comes from. The distinction matters for the bill: a scope that silently covers only public cloud leaves out the SaaS subscriptions, software licences and AI providers behind the same product, and so only partly answers what that product costs.
How it works
Scopes
For the Foundation, a scope frames decisions, settling who takes part, which capabilities are worked on and what counts as success; a practice usually has several. Capabilities such as Allocation or Forecasting keep their purpose in every scope; what a scope changes is how often they run, how strict the governance is, which KPI targets apply and how mature they need to be.
Scopes, the Foundation says, follow the decision context, not the infrastructure: one scope can take in everything a decision reaches, even across several products or environments, and spend within one area can be split into separate scopes when parts of it serve different goals or work under different constraints. A new scope earns its place only by changing a decision; each costs upkeep, so the Foundation advises keeping them sparse. Scopes are also situational: they usually start from a leadership question, such as what the company spends on AI, are defined once the decision behind it is clear, and end with that outcome.
In the Foundation's account, a practice often begins with its cloud usage as the first scope, the work commonly called Cloud FinOps; even that scope is defined by what the business expects from moving to the cloud, lower cost or faster delivery for example, more than by the cloud as a technology. Scopes beyond public cloud came later; for AI, the Foundation draws the scope around the investment and its purpose, not the platform.
Technology categories
A technology category is a kind of technology the spend comes from; each is bought and billed in its own way, which decides who invoices, in which unit, and how detailed the cost data is, as the table below sets out. On 2026-10-16 the Foundation lists five, one per row below. Each category page applies the Framework to that kind of spend and has a section on how far its billing data fits FOCUS. The Foundation added the category section in its 2026 revision of the Framework and does not present the list as complete.
Licences are no category of their own, though the Framework's overview still lists licensing beside cloud, SaaS and data centres; they belong to the capability Licensing & SaaS in the domain Optimize Usage & Cost. Where their cost shows up depends on how they were bought, the Foundation notes: licences bundled into a cloud resource or bought through a cloud marketplace appear in the cloud provider's billing data, others in the vendor's own billing. They are charged by seat, user, processor core or another unit, the commitment usually spans several years or is perpetual, and the company can often add licences during the term (a true-up) but not give any back.
What each category brings
| Category | Who invoices | Billing unit | Data source | Allocation key | Usual gap |
|---|---|---|---|---|---|
| Public Cloud | AWS, Microsoft, Google Cloud | Usage quantity per SKU: hour, GB, request | Usage export with daily line items, FOCUS | Account, subscription, project; tags and labels | Shared cost, such as one Kubernetes cluster line for many teams |
| SaaS | The vendor, directly or via reseller or marketplace | Seat or user per subscription, plus usage meters | Invoice, CSV export, admin API, contract | User list to department or cost centre | Credit card purchases, annual subscription beside monthly usage, resource level rarely available |
| Data Cloud Platforms | The platform, such as Snowflake or Databricks, or the cloud provider | Platform consumption units, which FOCUS can carry as a virtual currency | Query, job and pipeline telemetry, plus the invoice | Warehouse, workspace or job to team | Compute shared by several teams |
| Data Center | Hardware vendors, facility and maintenance contracts, utilities | Depreciation, facility leases, power and cooling, staff | Asset database or CMDB, power metering, accounting or ERP | Fixed allocation, consumption or defined recovery units to team | No consumption bill from a provider; total cost has to be assembled from costs that IT and facilities book separately |
| AI | The cloud provider (Amazon Bedrock, Microsoft Foundry, Gemini Enterprise Agent Platform), the model provider (OpenAI, Anthropic) or a SaaS product | Tokens, API calls, GPU hours, capacity reservations | Cloud billing data, provider usage reports, dashboards and logs | Project, key or tag to team or feature | Unclear who consumes the model output; incomplete provider billing data |
What it means for your cost
The category decides what the monthly loop can do with the data. For public cloud, and AI services on the cloud bill, an export carries every line item with tag, account and resource, so the loop can reconcile the invoice, trace changes to the resource and see anomalies daily. SaaS and licence costs mostly reach the company as the vendor's invoice, a CSV export or an admin API; as the Foundation's SaaS page notes, these are coarse and seldom go down to the resource; the data usually enters the reports through a file import, and the company supplies the allocation key, such as a user list, because the invoice contains none. Here the loop checks invoice against contract and paid against active seats but detects no daily anomaly; CSV and file imports covers what a file import can do. For AI providers that invoice directly, it hinges on a daily usage export; see AI provider usage exports and AI provider billing. Kubernetes cost data covers which data splits a Kubernetes line across owners.
The decision a scope forces is the boundary itself. In a company of 10 to 200 people, asking what a product costs can draw a scope across cloud bill, AI providers and SaaS tools behind it; everything else is deliberately left out and named. The pending decision, not the largest category, sets which scope comes first. What FinOps is shows how a scope relates to phases, personas and capabilities.
Where it goes wrong
- Scope equals category. Symptom: the Cloud FinOps scope covers the AWS bill, while the AI provider invoice for the same product, paid by card, appears in no report. Cause: the scope was drawn at the technology boundary, not around the decision.
- One scope for everything. Symptom: production, experiments and an AI pilot share one budget variance, and the pilot's spikes trigger production alerts. Cause: different tolerances can justify separate scopes within one area of spend, as the Foundation describes.
- Scopes without end. Symptom: a scope per team, tool and initiative, and nobody reads the reports any more. Cause: classification was mistaken for decision context.
- File data treated like export data. Symptom: a SaaS invoice is imported as one monthly line, and anomaly detection is expected on it. Cause: a monthly line has no daily granularity.
Sources
Read on 2026-10-16. FinOps Foundation: FinOps Scopes, Technology Categories, FinOps for SaaS, FinOps for Data Cloud Platforms, FinOps for Data Center, FinOps for AI, Licensing & SaaS, FinOps Framework, FinOps Framework 2026: Executive Strategy, Technology Categories, and Converging Disciplines.