TL;DR The FinOps Foundation defines six principles that guide how organizations manage cloud and technology spend. Most teams can recite them. Far fewer translate them into the day-to-day decisions, structures, and workflows that make cloud financial management actually work.
The six principles are collaboration, business value, ownership, accessible data, central enablement, and variable cost exploitation. The FinOps Foundation updated four of the six principles in 2025, the first revision since 2019, to reflect a broader "Cloud+" scope beyond public cloud. The three FinOps phases (Inform, Optimize, Operate) translate principles into execution. Operationalizing the principles requires a data foundation, a central enabling function, showback before chargeback, and continuous optimization loops. DoiT helps teams close the gap between principle and practice through unified cost analytics, automated workflows, and FinOps-certified cloud architects.
Most teams that adopt FinOps spend real time studying the six principles. They align on the definitions, get buy-in from leadership, and build a slide deck. Then they go back to reviewing cloud bills at the end of the month.
The gap between FinOps as a concept and FinOps as a working practice shows up here. The principles describe the right operating model for cloud financial management. They do not describe how to build it. That translation work, from principle to process and from intent to organizational habit, is where most programs stall.
This guide covers what each principle means in practice, how the three FinOps phases map onto them, and the specific implementation moves that turn principles into outcomes your team can actually measure. For a deeper look at how these principles connect to broader implementation strategy, see DoiT's guide to FinOps implementation.
What are FinOps principles, and where do they come from?
FinOps principles are the foundational values published by the FinOps Foundation, the vendor-neutral nonprofit that maintains the FinOps Framework. They act as the north star for any FinOps practice, guiding the cultural behaviors and organizational decisions that determine whether cloud financial management delivers lasting value or stays performative.
The six principles were originally crafted in 2019. In March 2025, the FinOps Foundation updated them for the first time as part of a broader Framework revision, reflecting how FinOps has expanded beyond public cloud into what the Foundation now calls a "Cloud+" approach. Four of the six principles were reworded to acknowledge that FinOps practitioners now manage SaaS, data centers, licensing costs, and private cloud alongside traditional infrastructure spend. The core meaning of each principle stayed intact; the language caught up with the reality of modern practice.
This article uses the current 2025 wording throughout.
The 6 FinOps principles in detail
Each principle carries a specific operational expectation. Understanding what the FinOps team has to build to honor it separates teams that apply the framework from teams that gesture at it.
1. Teams need to collaborate
Cloud cost is a cross-functional problem. Finance sets budgets but cannot interpret usage patterns. Engineering understands workloads but has limited visibility into financial impact. Product owns the roadmap decisions that drive spend. When these groups operate in silos, cloud bills grow and nobody owns the outcome.
Collaboration as a principle means building the structural conditions for shared decision-making: regular cross-functional reviews, a shared vocabulary for cloud cost, and shared KPIs that give finance and engineering a common basis for tradeoffs. The FinOps team's job is to facilitate that conversation, not to own it on behalf of everyone else. Teams that treat collaboration as an aspiration rather than a designed workflow consistently underdeliver on FinOps outcomes. See how FinOps best practices support cross-functional collaboration at scale.
2. Business value drives technology decisions
Before 2025, this principle read: "Decisions are driven by business value of cloud." The update broadened the scope. The shift from "value of cloud" to "drives technology decisions" signals that FinOps now applies the same value lens to SaaS subscriptions, AI workloads, and data infrastructure, not just cloud compute.
In operational terms, this principle means that every significant infrastructure decision connects to a business outcome. Not "this instance family is cheaper" but "this architecture reduces cost per transaction while maintaining SLA." It requires teams to build the measurement capability that makes those connections explicit: unit economics, cost per customer, cost per feature, cost per environment. Without that infrastructure, the principle is aspirational language.
3. Everyone takes ownership of their technology usage
The 2025 update replaced "cloud usage" with "technology usage," extending the ownership model to the full range of technology spend FinOps teams now manage. The underlying expectation stays the same: engineers, product managers, and application teams should understand the cost implications of their decisions and feel accountable for them.
Achieving this requires two things. First, cost visibility at the team level: engineers cannot own what they cannot see. Showback reports, cost allocation by team or product, and real-time spend dashboards give people the information needed to act. Second, cultural permission: teams will not optimize spend if they believe cost accountability conflicts with delivery speed. The FinOps program has to make clear that ownership means informed decision-making, not cost policing. For more on cost allocation strategy, see DoiT's breakdown of cost allocation by environment.
4. FinOps data should be accessible, timely, and accurate
The 2025 revision added "accurate" to this principle, which previously read "accessible and timely." The addition reflects a real practitioner pain point: teams that receive cost data on time but find it riddled with allocation errors or missing tags cannot act on it effectively. Accuracy is not implied by accessibility.
Operationally, this principle defines the requirements for the FinOps data foundation: cost data must reach the teams who need it quickly (daily or near-real-time, not monthly), it must be correctly attributed to the right teams and products, and it must be complete enough to support decisions. Late data leads to reactive responses. Inaccurate data erodes trust in the FinOps program entirely. Missing data creates blind spots that compound over time.
5. FinOps should be enabled centrally
This is one of the more significant rewordings from 2025. The original principle read "A centralized team drives FinOps." The update shifted to "FinOps should be enabled centrally," which the FinOps Foundation noted better captures the bottoms-up approach that effective FinOps employs.
The distinction matters. A centralized team that drives FinOps can become a bottleneck, another group doing cost work on behalf of everyone else. Central enablement means the FinOps function creates the tooling, processes, frameworks, and expertise that distributed teams use to manage cost themselves. It builds capability organization-wide rather than centralizing the work. The central team handles rate negotiations, commitment management, tooling, and governance. Engineering teams handle rightsizing and resource lifecycle within their own workloads.
6. Take advantage of the variable cost model of the cloud
Cloud infrastructure costs vary with usage. Unlike the fixed capital expenditure of on-premises infrastructure, cloud spend responds to decisions made at the workload level. This is an enormous operational advantage that many organizations fail to exploit fully.
Taking advantage of the variable model means building the engineering and financial practices that use variability strategically: auto-scaling to match capacity with demand, using commitments (Reserved Instances, Savings Plans, committed use discounts) to reduce the rate on predictable workloads, rightsizing to eliminate idle capacity, and moving workloads to lower-cost configurations when business requirements allow. Teams that treat cloud as fixed infrastructure miss the fundamental cost lever that makes FinOps valuable. For platform-specific approaches, see DoiT's Google Cloud FinOps best practices.
The three FinOps phases (Inform, Optimize, Operate) and how they map to the principles
The FinOps Foundation organizes execution into three phases: Inform, Optimize, and Operate. These phases describe what the FinOps team does, whereas the principles describe why and how they should do it. The phases translate principles into work.
1. Inform: visibility, attribution, and budgeting
The Inform phase addresses the data accessibility and accuracy principle directly. Before any optimization is possible, teams need to see their spend: what exists, who owns it, what it costs, and how it trends. Inform work includes establishing cost allocation through tagging, building showback reports that surface team-level spend, creating budgets and forecasts, and setting up anomaly detection to catch unexpected cost changes before they compound.
Most organizations underinvest here. They assume visibility is a solved problem because their cloud provider sends a bill. It is not. An itemized bill is not cost visibility. Cost visibility means every team can see their spend, correctly attributed, with enough granularity to take action. Getting there requires tagging governance, allocation logic, and tooling investment. Without a complete Inform foundation, Optimize efforts hit walls: teams try to rightsize workloads they cannot fully identify, or address anomalies they found out about weeks after they started.
2. Optimize: rightsizing, commitments, automation
The Optimize phase is where the variable cost model principle becomes executable. Armed with accurate, team-level visibility from Inform, teams can make structured decisions about spend reduction: rightsize over-provisioned resources, purchase commitments against predictable baseline workloads, eliminate idle and orphaned resources, and implement scheduling for non-production environments. For a comprehensive breakdown of optimization levers, see DoiT's cloud cost optimization strategies.
Optimize work also operationalizes the business value principle. Every optimization decision should connect to a business framing: cost per workload, cost per transaction, cost as a percentage of revenue. Teams that optimize without that connection tend to chase savings in isolation, sometimes trading performance or reliability for marginal cost reduction. The business value lens keeps optimization decisions anchored to outcomes that matter.
3. Operate: continuous practice and cultural integration
Operate is where the collaboration and ownership principles become cultural habits rather than stated commitments. In this phase, FinOps moves from project to practice: cost reviews become a regular part of engineering planning cycles, optimization recommendations feed directly into sprint work, and cloud spend connects to product roadmap conversations.
The Operate phase also surfaces the central enablement principle in its most visible form. A FinOps team that has to drive every optimization manually does not scale. The Operate phase works when the central FinOps function has embedded enough capability in engineering teams that cost accountability is self-sustaining: teams identify and address their own inefficiencies, escalate to the central function for complex decisions, and participate in cross-functional reviews as a routine part of how they work.
How to translate FinOps principles into a working practice
Principles do not become outcomes on their own. The following implementation sequence builds the operational layer that turns the six principles into measurable practice. For additional context on the full implementation journey, see DoiT's cloud financial management implementation guide.
Build the data foundation first
Before anything else, establish accurate, complete cost attribution. Implement a tagging standard that covers every resource: team, environment, application, cost center. Enforce it at provisioning time, not as a retroactive cleanup campaign. Set up allocation logic for shared infrastructure so costs land on the right teams. Establish anomaly detection with alerting thresholds so cost surprises surface quickly.
Without this foundation, every downstream FinOps initiative operates on incomplete information. Rightsizing decisions miss the workloads that lack tags. Budget conversations fail because finance and engineering have different numbers. The data foundation is non-negotiable, and it requires upfront investment before teams see results.
Establish the central enabling function (not a cost-control team)
The FinOps team's mandate matters. Frame it as a function that creates capability and drives value, not a team that enforces budgets or owns cost reduction as a target. The distinction shapes how engineering teams engage with FinOps and determines whether the collaboration principle takes hold.
The central function handles the work that requires specialized expertise and organizational scope: commitment purchasing and management, rate negotiations, tooling selection and maintenance, governance policy, and cross-functional review facilitation. Engineering teams handle the workload-level decisions that require domain knowledge the FinOps team does not have. That division of responsibility is what makes central enablement scale.
Implement showback before chargeback
Showback means giving teams visibility into their cloud spend without financial consequence. Chargeback means allocating those costs directly to team or product budgets. Start with showback.
Chargeback before teams have reliable cost data and established ownership creates friction that damages the FinOps program's credibility. Teams contest allocation methods, dispute bills they do not understand, and lose trust in the data. Showback builds the familiarity and data quality needed for chargeback to work. It also surfaces ownership questions that need resolution before financial accountability takes hold. Most organizations that rush to chargeback spend the next year relitigating the same allocation disputes they could have resolved during a showback phase.
Make optimization continuous, not quarterly
Manual quarterly reviews do not match the pace at which cloud environments change. New services get provisioned. Workloads scale. Configurations drift. A quarterly audit catches what happened three months ago. By then, the cost of the problem is already realized.
Continuous optimization means automated detection of rightsizing opportunities, idle resources, and cost anomalies, fed into a regular cadence of engineering review. Recommendations surface on a weekly or sprint cycle, get prioritized alongside feature work, and get tracked to completion. This workflow operationalizes both the data accessibility principle and the variable cost model principle: it uses timely data to make ongoing decisions that exploit the flexibility cloud provides. For a reference set of metrics to track against, see DoiT's FinOps KPIs guide and the broader FinOps tools overview.
Connect cloud spend to business outcomes
Unit economics anchor the business value principle in something measurable. Cost per active user, cost per transaction, cloud spend as a percentage of revenue, cost per deployed feature: these metrics translate infrastructure spend into language that product, finance, and executive stakeholders understand and use to make decisions.
Building unit economics requires combining cost data with product and usage data: transaction volumes, user counts, deployment events. Most FinOps programs defer this work because it requires cross-system integration. Teams that do the integration consistently make better tradeoff decisions, because they can answer "what does this architecture change actually cost per customer?" rather than operating on aggregate monthly totals.
Common pitfalls when applying FinOps principles
Several patterns look like FinOps but fail to deliver the outcomes the principles describe.
Confusing reporting with FinOps. Building dashboards and distributing spend reports is not a FinOps practice. Reporting is the prerequisite. FinOps begins when teams use that data to make decisions that change outcomes. Organizations that invest heavily in reporting tooling and then skip the governance and optimization work have built infrastructure for a practice they have not actually started.
Treating cost reduction as the goal. Cost reduction is an output of effective FinOps, not the objective. The objective is business value from technology spend: the right resources, running the right workloads, at the most efficient cost point for the performance and reliability required. Teams that target cost reduction directly tend to optimize in ways that compromise reliability, undermine engineering trust, or create short-term savings that cost more to maintain than they were worth.
Underinvesting in the central enabling function. FinOps programs staffed with a single analyst and a spreadsheet cannot deliver the capability the principles require. Commitment management, governance, cross-functional facilitation, tooling, and anomaly response all require dedicated capacity. Organizations that understaff the central function and then express frustration with FinOps outcomes have confused the principle of central enablement with the idea that FinOps should be cheap to run.
Ignoring engineering trust. If engineers experience FinOps as cost policing, budget alerts, mandatory reviews, and friction added to provisioning, they disengage. The collaboration and ownership principles require engineering teams to want to participate. That requires the FinOps team to engage as a partner that removes obstacles and creates efficiency, not a compliance function that adds overhead. Trust takes time to build and can be lost quickly if the FinOps program's first visible actions feel punitive.
From FinOps principles to FinOps practice
The six FinOps principles describe the destination. They define what a mature cloud financial management practice looks like when it works: cross-functional collaboration, business-value-connected decisions, distributed ownership, reliable data, centrally enabled capability, and systematic exploitation of cloud's variable cost model.
Getting there requires the operational layer underneath: a tagging and allocation foundation, a FinOps team with the right mandate, a showback-first rollout, continuous optimization workflows, and unit economics that connect spend to the business metrics executives actually track. None of that happens automatically. It requires investment, sequencing, and sustained commitment across engineering, finance, and operations.
DoiT supports this journey through unified cost analytics, automated optimization workflows, and FinOps-certified cloud architects who work alongside your team to turn insight into execution. If you are ready to move from principle to practice, talk to a DoiT FinOps expert.
Frequently asked questions about FinOps principles
How many FinOps principles are there?
There are six FinOps principles, as defined by the FinOps Foundation. They are: 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. These six principles apply across the full range of technology spend that FinOps teams manage, including public cloud, SaaS, data centers, and private cloud infrastructure.
What's the difference between FinOps principles and FinOps phases?
FinOps principles are the foundational values that define how FinOps should work, what the practice stands for and where it is headed. FinOps phases (Inform, Optimize, Operate) describe how teams execute against those values. Principles answer the question of what kind of practice to build. Phases answer the question of how to build it and what work to do at each stage of maturity. A team can be in the Inform phase while working toward all six principles simultaneously, using visibility work to operationalize the data accessibility and collaboration principles before moving into optimization.
Where do FinOps principles come from?
The six FinOps principles come from the FinOps Foundation, the vendor-neutral nonprofit that maintains the FinOps Framework. The Foundation is the recognized authority on FinOps practice, and its principles reflect input from a global community of practitioners. The principles were originally crafted in 2019 and updated for the first time in 2025 to reflect how FinOps has expanded beyond public cloud into a broader Cloud+ approach. The FinOps Foundation also publishes detailed guidance on each principle, along with maturity indicators, persona-specific views, and supporting capabilities that help teams apply them in practice.text