The six FinOps principles are the statements the FinOps Foundation places under its Framework: Teams need to collaborate, Business value drives technology decisions, Everyone takes ownership for their technology usage, FinOps data should be accessible, timely, and accurate, FinOps should be enabled centrally, and Take advantage of the variable cost model of the cloud. The Framework is licensed CC BY 4.0; this handbook keeps the Foundation's names and paraphrases their meaning as read on 2026-10-16. For the bill, each principle settles who has to see a line item, how soon, and which decision follows. What FinOps is explains FinOps as a whole.
How it works
The Foundation sets the six principles side by side in no particular order and calls each important to FinOps success. That makes them no checklist: they fix the standards by which an organisation decides about technology spend, before phases, capabilities and maturity levels describe the how.
The six principles
Teams need to collaborate. The Foundation reads this as finance, engineering, product and leadership steering technology spend together, at the pace and in the depth each technology demands. With a handful of accounts it means that the person who pays and the person who runs the resources look at the same numbers in the same month.
Business value drives technology decisions. For the Foundation, what counts is cost in relation to what it produces: unit metrics and value-based measures say more than the aggregate, and trade-offs between cost, quality and speed are made deliberately. For a small company this puts the cost of a customer, a tenant or an order ahead of the question of where to save.
Everyone takes ownership for their technology usage. The Foundation places responsibility for usage and cost with the people who design and run the systems, from architecture to operations, inside budgets they help shape. Without a FinOps function, this is where cost actually moves: whoever starts an instance sees in the cost data what it costs.
FinOps data should be accessible, timely, and accurate. Cost data, in the Foundation's reading, is shared as soon as it exists, is consistent at every level of the organisation and carries forecasting, variance analysis and internal comparison; for consistency the Foundation points to FOCUS. For the bill this means an export of the billing data that someone actually reads, not a PDF invoice filed once a month.
FinOps should be enabled centrally. A central place, the Foundation says, sets standards, bundles the decisions on rates, commitments and discounts to capture economies of scale, and keeps the conversation with leadership in one voice, so that engineering can concentrate on its own usage.
Take advantage of the variable cost model of the cloud. The Foundation treats every cost model, the cloud's variable one, the data centre's fixed one and others, as having strengths and weaknesses and as a source of value; decisions should weigh the cost model alongside technical requirements, buy capacity just in time where that pays, plan iteratively and adjust architecture continuously instead of cleaning up occasionally. For the bill it means that every line item arises anew each month and can therefore be decided anew each month.
Enabled centrally without a central team
A company of 10 to 200 people rarely has a FinOps function. The principle speaks of a central FinOps team or function; it does not say that function has to be a department. In a company of this size it can be one place where three things meet: the standard for cost allocation, meaning which accounts, projects and tags exist and what they mean, the decision on commitments, and the cadence at which reports are read. In practice that place is the person who pays or approves the invoice, together with the engineering lead. How roles carry a practice without a team is the subject of FinOps without a FinOps team; what "everyone takes ownership" looks like as role design, of FinOps roles and responsibilities.
The variable cost model and commitments
The sixth principle does not mention commitments. What follows from it is that a commitment is a cost-model decision: chosen deliberately for usage stable enough to carry it, with the variable model's flexibility kept where usage fluctuates. The instruments and how they appear on the bill are covered by AWS Savings Plans and the chapter Pricing models and commitments.
What it means for your cost
In a small company each principle is carried by an artefact, and the artefact shows whether the principle is practised. The table maps each principle to its artefact and to the chapter that treats it.
| Principle | Artefact in a small company | Chapter |
|---|---|---|
| Teams need to collaborate | a monthly cost review with finance and engineering | Reporting and analysis |
| Business value drives technology decisions | a unit cost metric per product or customer | Allocation and ownership |
| Everyone takes ownership for their technology usage | a named owner per account, project or tag value, and a cost report per owner | Governance and the operating model |
| FinOps data should be accessible, timely, and accurate | an export of the billing data and reports everyone can read | Billing data and standards |
| FinOps should be enabled centrally | an allocation rule (account structure, mandatory tags) and one place for commitment decisions | Allocation and ownership |
| Take advantage of the variable cost model of the cloud | a budget per scope and a documented commitment decision | Budgets, forecasts and finance |
In the billing data the principles show in three places: the unallocated remainder measures how far ownership and the central standard reach, the number of people who open the monthly report whether the data is accessible, and the ratio of commitments to variable usage whether the sixth principle is applied deliberately. The principles carry no maturity score; the Framework measures capabilities elsewhere. How the principles become work in the three phases is described in Inform, optimize, operate: the three FinOps phases; what the 2026 Framework changes for small teams, in FinOps Framework 2026: what small teams should actually change.
Where it goes wrong
- Principles as a checklist. Symptom: a document ticks all six principles, yet the invoice is still read by one person alone. Cause: the principles were taken as a state to reach, not as the standard against which every spending decision is measured.
- Ownership without data. Symptom: engineering is made responsible for cost but gets no report that shows its own resources. Cause: the third principle was introduced before the fourth was met; responsibility without accessible data stays an assignment on paper.
- "Centrally" taken to mean "finance alone". Symptom: finance reconciles the invoice and decides on commitments, and engineering learns of it from the bill. Cause: the central place was confused with a department; the principle means standards and bundled decisions that every participant knows.
- A variable model nobody decided on. Symptom: either everything runs at list price, or everything is bound for years. Cause: nobody separated the stable base load from the fluctuating usage, so the commitment decision was never taken deliberately.
Sources
Read on 2026-10-16. FinOps Foundation: FinOps Principles, FinOps Framework, What is FinOps?. FOCUS: FinOps Open Cost and Usage Specification.