Finops Standards

FinOps standards

Criteria verified as of August 2026. Re-verify on the web before committing to anything (§8).

1. Scope and triggers

FinOps is the discipline of deciding with cost as an engineering metric, not a monthly report on the invoice. A report describes the past and changes nothing; an engineering metric enters the design review, the PR and the alert, and blocks or unblocks decisions. If cost only shows up on a slide at the end of the month, there is no FinOps practice here: there is accounting.

Hard constraint of this skill: it keeps the METHOD and cedes the specific SERVICE. The cost criteria for a given service —which instance class, which storage tier, which billing model that managed database has, which flag makes it cheaper— already live in aws-standards, azure-standards and gcp-standards, and that is where they are decided. Here we decide how it is measured, how it is allocated, who is accountable and which gate enforces it, independently of the provider. If this skill and a cloud skill give a figure about the same service, the cloud skill wins.

Covers: the FinOps framework and its vocabulary (phases, domains, capabilities, Scopes), unit economics, allocation (tagging and its governance, account hierarchy, shared cost), commitments and discounts, the impact order of the levers, the hidden-cost catalogue, forecasting and budgeting, anomalies, showback/chargeback, normalising billing data with FOCUS, cost in Kubernetes, AI inference cost and tooling (OpenCost, Kubecost, Infracost).

Not applicable: see aws-standards, azure-standards, gcp-standards (the specific service, its pricing model and its configuration are theirs; here the method, unit economics, allocation and governance), kubernetes-standards (requests, limits, autoscaling and scheduling; here only the cost they produce and its split across tenants), iac-standards (tagging is enforced in the code: the tool, the module and the state are theirs; the tag policy —which keys, which values, what is mandatory— is from here), data-platform-standards, lakehouse-standards and data-engineering-standards (scan cost and partitioning as a cost decision already live there: this skill does not re-decide a Parquet layout or a partition key, it only demands that that cost has an owner and a unit), gpu-computing-standards (the GPU as an expensive resource that is shared, measured and planned is already theirs; here inference cost as a spend category and its unit), caching-cdn-standards (egress, hit ratio and CDN billing), object-storage-standards (classes, lifecycle and per-request cost), sre-practice-standards (reliability versus cost is an explicit trade-off and the error budget is theirs: no cost optimisation is approved here if it consumes error budget without a decision recorded there), green-it-standards (carbon footprint and energy efficiency; cost and emissions correlate but are not the same metric —§6.4), grc-compliance-standards (internal control, audit and segregation of duties over spend), platform-engineering-standards (the cost of the internal platform is one more unit economic and is measured with the method from here; tagging gates are implemented in their paved road and in their admission layer), enterprise-architecture-standards (the cost per application produced by this skill is one of the inputs to their lifecycle decision —tolerate, invest, migrate, eliminate—; the inventory, the criticality and the governance of the standard are theirs. An expensive application with no owner is not a cost problem, it is a portfolio problem), green-it-standards (reciprocal boundary because the two share levers and do not share a metric: switching off what is idle, right- sizing and choosing a region reduce cost and carbon, which is why they get confused. Unit economics belong here; the carbon unit is theirs. They diverge more than it looks: the embodied footprint of hardware makes extending the useful life of a machine weigh more than optimising its consumption, which can contradict a replacement decision taken on cost alone; and a cheap region is not necessarily a low-carbon-intensity region. When the two metrics point in opposite directions, both are declared and the business decides — neither skill trims the other in silence).

2. Default decisions

Verify the latest version and the state of the cited sources on the web before committing to anything (§8).

2.1 Tool status and licence (verified raw)

The licence trap, the one most often missed: the CLI being Apache-2.0 does not make the service free. Infracost is the canonical case: permissive code, hosted pricing API with a quota. The purchasing decision is taken on the service, not on the LICENSE. Before pinning any of these three as a project default: read its raw LICENSE and its pricing page on the same day (§8).

2.2 The FinOps framework, 2026 edition (verified)

Current definition, verbatim from finops.org: "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." (published on 19 Mar 2026).

• Phases (verbatim): Inform · Optimize · Operate. Maturity, verbatim: "A FinOps approach of 'Crawl, Walk, Run' enables organizations to start small, and grow in scale, scope, and complexity."
• 4 domains and 22 capabilities (verbatim from the framework page):
  • Understand Usage & Cost: Data Ingestion · Allocation · Reporting & Analytics · Anomaly Management
  • Quantify Business Value: Planning & Estimating · Forecasting · Budgeting · KPIs & Benchmarking · Unit Economics
  • Optimize Usage & Cost: Architecting & Workload Placement · Usage Optimization · Rate Optimization · Licensing & SaaS · Sustainability
  • Manage the FinOps Practice: Executive Strategy Alignment · FinOps Practice Operations · Governance, Policy & Risk · FinOps Education & Enablement · Invoicing & Chargeback · FinOps Assessment · Automation, Tools & Services · Intersecting Disciplines
• Changes in the 2026 edition (this one has genuinely been reviewed and extended, do not assume the previous edition): Executive Strategy Alignment is a new capability in Manage the FinOps Practice; the Scopes construct is deepened with more Technology Category pages; convergence with adjacent disciplines is added; and the definition is updated. The rename from "Optimize Cloud Usage and Cost" to "Optimize Usage & Cost" comes from the 2025 edition, which was the one that introduced Scopes as an element of the framework.
• Scope, verbatim: "A FinOps Scope is a defined segment of technology-related spending – aligned to business constructs such as products, cost centers, or environments." The operational consequence: the framework is no longer only about public cloud — SaaS, licences, data centre and AI are technology categories in their own right.
• The FinOps Foundation is a Linux Foundation programme and updated its mission, verbatim: "from 'Advancing the People who manage the value of Cloud' to 'Advancing the People who manage the Value of Technology.'"

Do not use the framework as an org chart template. It is a common vocabulary so that engineering, finance and business say the same thing with the same words, and a capability map for spotting gaps. Setting up a committee per capability is the usual way to fail with it.

3. Structure and conventions

3.1 Unit economics is the only indicator that matters

Hard rule: every system with material cost declares a unit economic before any optimisation action is approved for it. With no denominator there is no optimisation, there is cutting.

unidad_económica = coste_asignado_del_sistema / unidad_de_valor_del_sistema

The unit of value is set by the product owner, not by engineering, and there is one per system: cost per transaction, per active user (DAU/MAU), per request served, per GB processed, per order, per document indexed, per token or per use case resolved in AI.

Why absolute total spend is a misleading metric in a growing system: a service that goes from €100,000 to €130,000 a month while tripling its traffic has improved its efficiency by 57 %, and in the report it shows up as a +30 % deviation. The practical consequence is worse than the statistics: penalising the absolute rewards not growing and punishes the team that absorbed demand. And conversely: a flat total with falling traffic is a silent deterioration. Corollary: a budget alert on an absolute value is not an efficiency alert; it serves treasury and the spend ceiling, not the evaluation of engineering.

Rules for the metric:

• It is published next to the business metric that denominates it, on the same dashboard. A cost figure without its denominator visible is not published.
• It is compared against itself over time, not against another team nor against a provider benchmark. A valid target is written as "cost per order ≤ €X by date Y", not as "cut spend by 20 %".
• It is recalculated when the denominator changes (a change in the definition of "active user") and the change is annotated on the series: a time series with the definition changed halfway through is a lie.
• A system with no identifiable unit of value (internal tool, platform) uses cost per team served or cost per service deployed — but it declares one.

3.2 Allocation: tags, hierarchy and shared cost

A tag policy with no gate enforcing it does not exist. It is the central rule of this section: the naming document that nobody can mechanically breach produces, six months later, a fraction of non-allocatable spend that grows on its own. Therefore:

1. Policy declared as code, not in a wiki. Minimum mandatory set, with closed-domain values wherever possible:

   Key	Mandatory	Values	What it decides
   owner	Yes	Team identifier from the directory, not a personal email	Who gets asked and who switches it off
   cost-center	Yes	Closed list from finance	Accounting split
   service	Yes	Name from the service catalogue	Joining cost with unit economics
   environment	Yes	prod / staging / dev / sandbox	Non-production sweep (§3.5)
   data-classification	Yes if there is data	Classes from grc-compliance-standards	Cost/retention cross-check
   expires	Yes in sandbox and ephemeral	ISO-8601 date	Automatic shutdown

2. Gate 1 — IaC: the resource is not created without the mandatory keys. The tool (policy as code in the plan, modules with default tags, provider default tags) is decided by iac-standards; the list of keys and their valid values is decided by this skill.

3. Gate 2 — admission: in Kubernetes, an object without the mandatory labels is rejected in the admission controller (implementation: platform-engineering-standards).

4. Gate 3 — detection: weekly report of non-taggable spend, with a hard threshold: if non-allocatable spend exceeds 5 % of the total, allocation is not reliable and no split decisions are taken until it is fixed. That 5 % is a governance threshold proposed here, not an empirical industry figure: adjust it to the size of the account, but set one and write it down.

Known limit of tagging, non-negotiable: there are costs that carry no tag by construction (support, platform fees, inter-zone traffic, services with no resource dimension, organisation-level commitment discounts). That is why:

The hierarchy of accounts/subscriptions/projects is the primary allocation boundary, and tags the secondary dimension. Reason: the account boundary enforces itself, does not depend on someone writing it correctly and survives resources that do not accept tags. Design rule: one account/project per (team × environment) as the default grain; group further only with written justification, because every grouping turns direct cost into shared cost.

Shared cost and how it is split. Categories: platform (cluster, mesh, CI), observability, network and Internet egress, security, licences, support and commitment discounts. Default method, in this order:

1. Real consumption metric if it exists and is cheap to obtain (CPU·hour and GiB·hour reserved in Kubernetes; GB ingested in logs; requests on the internal API).
2. Proportional to the consumer's direct cost, if there is no metric.
3. Fixed split per head/team only for the irreducible (support, corporate licences).

Why a perfect split is not worth it: the split has an engineering cost and a political cost that grow much faster than its precision. Operational criterion: the split model is refined only while a change in the split could change a decision. If going from 90 % to 97 % precision makes no team act differently, the work is pure accounting theatre — declare it unallocated, split it simply and in a documented way, and put that effort into unit economics. A stable and understandable split model is worth more than an exact one that nobody understands nor can challenge.

3.3 FOCUS: normalise before analysing

FOCUS (FinOps Open Cost and Usage Specification) is the most actionable piece of the domain and the only point where an open standard replaces N proprietary schemas. Verified status: version 1.4, ratified by the FOCUS Steering Committee on 4 Jun 2026; earlier versions 1.3, 1.2 (29 May 2025), 1.1 (7 Nov 2024), 1.0.

Criteria: the consumption layer (dashboards, alerts, unit economics, splits) is built against FOCUS columns, not against the provider's proprietary schema. The native export is ingested as is and transformed into FOCUS in the modelling layer; nobody writes a business query against a column name that only exists in one provider. The real and verifiable benefit: the same query answers across all three clouds and a migration does not rewrite the dashboards.

Columns you have to be able to tell apart (exact names from the specification):

Derived rule, the one most often broken: using BilledCost for unit economics produces false steps — the month a reservation is bought efficiency collapses and the next one looks miraculous. Unit economics and showback always go with EffectiveCost; accounting reconciliation, with BilledCost.

Other decision columns: ChargeCategory (Usage/Purchase/Tax/Credits/Adjustments) to separate consumption from purchase; ChargeClass to isolate corrections; CommitmentDiscountId, CommitmentDiscountType and CommitmentDiscountStatus to measure coverage and utilisation (§3.4); SkuId, ConsumedQuantity, ConsumedUnit, PricingQuantity, PricingUnit; ServiceCategory; Tags; InvoiceId.

Changes in 1.3 and 1.4 that shift criteria:

• 1.3 (ratified on 4 Dec 2025) added the columns for explicit shared-cost allocation — AllocatedResourceId, AllocatedResourceName, AllocatedMethodId, AllocatedMethodDetails — and the Contract Commitment dataset, plus data recency and completeness markers. Direct consequence: the split method stops being a secret in a spreadsheet and starts travelling with the data; demand it from your generators.
• 1.4 adds the Invoice Detail and Billing Period datasets and ~17 commitment columns, so that reconciliation with accounts payable is done against the same data that engineering uses. The four datasets of 1.4: Cost and Usage (mandatory), Billing Period, Contract Commitment and Invoice Detail.
• Declared discrepancy: on the ratification date of 1.3, the specification page gives 4 Dec 2025 and there are secondary sources saying 5 Dec 2025, with the public announcement on 11 Dec 2025. The specification's date is used; if it matters contractually, verify it in the repository changelog.
• Uneven coverage: per-provider adoption lags the specification (there are general-availability announcements for 1.2 coexisting with the publication of 1.3/1.4). Never assume your provider emits the latest version: check it before designing the model. There is also a conformance certification programme for data generators announced for 2026: verify its status before demanding it by contract (§8).

3.4 Commitments and discounts

Reserved instances, savings plans, committed-use discounts and their equivalents in other providers. Committing is a bet on the future architecture, it is not an optimisation: flexibility is traded for a discount, and whoever signs accepts the risk that the system being committed to stops existing before the commitment does.

Decision criteria, in order:

1. First right-size, then commit. Committing over an oversized fleet buys the mistake for three years. Reversing the order is forbidden.
2. Target coverage over the stable floor of consumption, never over the peak nor over the average. The floor is computed with the low percentile of daily consumption over the last few months, and the coverage target is written as the team's own decision, with its window and its percentile. No universal percentage is set here: whoever gives you an "80 % coverage" as an industry truth is not looking at your load profile. What is a rule: coverage is decided on a documented historical series, not on intuition.
3. Two mandatory metrics, and they are different: coverage (what fraction of eligible consumption is under commitment) and utilisation (what fraction of the purchased commitment is being used). High coverage with low utilisation is burned money; 100 % utilisation with low coverage is an unexploited discount. Both come out of CommitmentDiscountId/Status in FOCUS.
4. The term is chosen by the expected life of the architecture, not by the discount. Falsifiable rule: if the team cannot write down why that service will still exist in that shape at the end of the term, the term is too long.
5. Prefer the most fungible commitment (the one covering broad families/regions/services) over the most specific one, unless the discount difference is quantified and consumption is rigid and demonstrated.
6. Owner and review date: every commitment has a named accountable person and a review before expiry. A commitment renewed out of pure inertia is a mistake that doubles.
7. Secondary market and cancellation: before signing, verify whether the specific commitment can be sold, exchanged or cancelled and with what penalty — that is decided by the corresponding cloud skill, but do not sign without having looked.

3.5 The levers, in order of real impact

The order matters because the effort is almost always spent in the wrong place. From highest to lowest return per engineering hour:

1. Switch off what is not used. It is the only one that gives 100 % savings on the resource and has no architectural risk. Targets: non-production environments outside working hours, orphaned resources (unattached volumes, old snapshots, reserved public IPs with no use, load balancers with no targets, addresses and NAT with no traffic), expired sandboxes (expires), test clusters, data in hot classes that nobody reads, and whole services that nobody calls any more — cross cost with observed traffic, not with the team's opinion.
2. Right-size. Adjust to observed demand (not to requested demand), autoscaling, scale to zero where the model allows it. Controlled risk: margin is traded for cost, and that margin is reliability → coordinated with sre-practice-standards.
3. Choose the right pricing model. On demand / spot capacity (spot) / committed, storage classes and lifecycle, included licence versus your own. It is the lever with the best effort/savings ratio once 1 and 2 are done, and the one that goes worst if done earlier (§3.4, rule 1).
4. Architecture. Change the pattern: eliminate data shuffling between zones, replace polling with events, move compute next to the data, replace an expensive managed service with a cheaper one at the same SLO, change the format or the compression.

Why architectural optimisation arrives late if it was not thought about at design time: when the system is in production with customers, changing the pattern means data migration, coexistence, client rewrites and a risk window — months of work whose savings are compared against switching off idle resources in an afternoon. The cost of an architecture is fixed at the design review, and that is where the estimate has to go. Hence the gate in §4.2: the cost estimate is a design deliverable, not one from the invoice post-mortem.

3.6 The hidden-cost catalogue

What shows up on the invoice and nobody planned for. It is reviewed in full at every design review:

3.7 The cost of AI inference

A new category and already a first-order one: the framework treats it as its own Technology Category (FinOps for AI) within Scopes, and the annual survey places it as the future priority declared by practitioners (§6.6, with its methodology caveat).

Criteria:

• Mandatory unit economics, and a business one, not a technical one. Cost per token works as a normalising metric between models —the framework's guidance defines it as Cost Per Token = Total Cost / Number of Tokens Used— but it is not the decision metric: the decision metric is cost per use case resolved (query answered, document summarised, ticket closed). Cost per token can fall while cost per resolved case rises, because the system retries more or reasons for longer. If you only measure tokens, you do not see that.
• Break the token down: input versus output, cached versus uncached, and per model. They are different prices and different levers; aggregating them hides the only cheap optimisation that exists (prompt caching and choosing the model per task).
• Measure retries and errors: a failure that is retried is paid for twice and produces no value. Retry cost as its own line.
• Separate training/fine-tuning (batch, schedulable, suitable for spot capacity) from inference (interactive, with an SLO). They are opposite purchasing profiles.
• Dedicated GPU versus per-token API: the break-even point depends on the real utilisation of the GPU, and the GPU is paid for whether it is busy or not. Sizing, sharing and measuring GPU utilisation belong to gpu-computing-standards; here only the rule: no GPU is bought or reserved without a measured utilisation series.
• FOCUS already covers it with no special columns: generators express AI consumption with a per-token charge SkuId and ConsumedUnit/ConsumedQuantity in tokens. Do not invent a parallel schema.
• See llm-app-engineering-standards, rag-standards and local-inference-standards for the technical levers (cache, model routing, quantisation); here only their accounting.

4. Quality and gates

4.1 The gates, in increasing order of cost

4.2 The cost gate in the PR: how to do it right

• Start by informing, not blocking. A gate that blocks from day one with estimates that the team does not understand gets switched off in two weeks. Sequence: comment → high threshold that breaks → adjusted threshold.
• The threshold is on the estimated monthly delta, not on the total, and the repository sets it. Write it in the repo; do not inherit it from a tool default.
• Estimate ≠ invoice. The estimate does not know the usage (requests, egress, scaling). It is compared with reality at least once a quarter on the large systems; if the deviation is systematic, the model is fixed or the number stops being used to decide.
• An architectural change with cost impact is not approved without an estimated figure in the PR description or in the ADR. It is the gate that saves the most and the only one that acts in time (§3.5).

4.3 How to prove the cost data is correct

Covering the happy path and the edges, because a broken cost model is worse than not having one: it gives false confidence.

• Reconciliation: the sum of BilledCost for the period matches the provider's invoice, with a declared tolerance. Without this, everything else is decorative.
• Allocation closure: Σ (allocated cost) + unallocated = total, and unallocated ≤ threshold (§3.2). Automated test, not visual review.
• Edges that must be tested explicitly: credits and promotional discounts (ChargeCategory = Credits) that mask the real cost; retroactive corrections (ChargeClass) that rewrite closed months; currency change; 28/31-day months compared without normalising; one-off purchases (ChargeCategory = Purchase) contaminating the consumption series; resources created and destroyed within the same period; taxes.
• Test of the series itself: a dashboard that changes shape when the definition of the unit economic changes and does not annotate it is broken. Annotating definition changes is mandatory.

5. Security and governance of cost data

• Billing data is sensitive business information: it reveals volume, customers, growth and architecture. It is classified at least as internal, with role-based access control and query auditing. A cost dashboard open to the whole organisation is a decision, not an oversight.
• Credentials for cost tools: read-only, always. OpenCost/Kubecost/third-party agents do not need write permissions. A FinOps agent with shutdown permission is a denial-of-service switch with access to the whole account.
• Automation that switches resources off is a destructive action: non-production environments only, an explicit exclusion list, prior notice to the owner, and never deletion — switch-off or a reversible class change. Deletion is authorised by a person.
• Third-party FinOps SaaS: it receives the full billing export, which is a map of your infrastructure. Vendor due diligence, least privilege, encryption and a documented contract exit before signing (grc-compliance-standards).
• Cost optimisation cannot degrade security or compliance controls without a recorded decision: audit log retention, backups, encryption, high availability and multi-region are not fat. If a cost action touches one of these, it goes to an ADR and is signed by whoever is accountable for the risk, not by whoever is accountable for the budget.
• Fraud and abuse: a cost spike can be a security incident (mining after a credential compromise, mass exfiltration that drives up egress). The cost anomaly alert is also routed to security, not only to finance — it is one of the fastest and cheapest detectors that exist (incident-response-forensics-standards).

6. Operation: forecasting, budgeting and splits

6.1 Anomalies

• An anomaly alert with no named owner and no runbook is not created. An email to a distribution list is noise with an attention cost.
• Detection is done on the series at the granularity at which someone can act (per service and account), not on the organisation total: in the total, everything cancels out and nothing is visible.
• Double threshold mandatory: relative (deviation from expected) and absolute minimum. Without the absolute, a €3 resource that doubles generates the same alert as a €30,000 one.
• Every anomaly is closed with a cause (code change, traffic change, provider price change, error, security incident), not with "resolved".

6.2 Forecast versus commitment

They are two different things and confusing them is the expensive mistake: the forecast is an estimate with uncertainty that serves for planning; the commitment is a signed contractual obligation (§3.4). You do not sign a commitment with the central scenario of a forecast, you sign with its conservative floor. The forecast is published with its interval and with its assumptions written down (traffic growth, planned launches, known price changes); a forecast with no written assumptions is not auditable and is useless for negotiating.

6.3 Budget

• The budget is set on the allocation unit that has an owner (account/project/team), not on fragile tags.
• Tiered thresholds with a different action at each one (notice to the owner → review with finance → freeze on creating new resources in non-production). A threshold with no associated action is decoration.
• It is FORBIDDEN for an exceeded budget to stop production deployments automatically: that turns an accounting deviation into an availability incident. It also applies to the admission quota implemented by platform-engineering-standards: it can hold back new resources and ephemeral environments, not the rollout of a service already in production.
• Renegotiating an SLO downwards because it does not fit the budget is a legitimate and ruled decision, not a silent cut. Procedure, agreed with sre-practice-standards: this skill supplies the cost per nine —what the redundancy, the multi-zone or the retention that sustain the target cost—; only whoever is accountable for the SLO changes the target, by signed ADR, with the user impact declared and communicated to whoever depends on the service. Without that ADR there is no renegotiation: there is a cut that will be discovered in the next outage.

6.4 Cost and sustainability

They correlate but are not the same metric and treating them as one leads to false decisions: switching off idle resources improves both; moving a workload to a cheaper region can worsen the footprint if that region has a worse energy mix, and vice versa. Rule: if a decision is justified by sustainability, it is measured with its own metric and the effect on cost is declared, and vice versa. The criteria for footprint, emission factors and methodology belong to green-it-standards; here only the warning not to use cost as a proxy for the footprint. The FinOps framework does have Sustainability as a capability of the Optimize Usage & Cost domain: use it as a point of contact, not as a source of calculation methodology.

6.5 Showback versus chargeback

Hard rule: charging a team a cost it has no control over (a platform decision, a shared service it did not choose) is not chargeback, it is a tax — it generates accounting disputes and zero savings. If the three conditions are not met, it stays at showback.

6.6 Practice metrics

The practice is measured by what changes decisions:

• Allocation coverage (% of spend with an identifiable owner) — the enabler of everything else.
• Declared unit economics over systems with material spend (%).
• Trend of each unit economic, per system.
• Time from the anomaly to its identified cause.
• Commitment coverage and utilisation (§3.4).
• Non-production cost as a fraction of the total.
• Forecast deviation versus actuals, and whether that deviation is shrinking.

Forbidden to measure the practice by cumulative absolute savings: it is the metric that can be invented (it is enough to inflate the reference price it is compared against), it does not distinguish real savings from avoided growth, and it rewards one-off cutting over sustained efficiency. If savings must be reported, they are reported with the baseline, the date and the calculation method written down, and their expiry is marked.

On industry figures — methodological warning. The State of FinOps from the FinOps Foundation (2026 edition, published on 19 Feb 2026) is the most cited public source: 1,192 respondents, and headlines such as "98% are managing AI spend" (versus 31 % two years earlier), "Nine of 10 practitioners are now being asked to manage SaaS", "64% manage licensing" and *"48

…(truncated)