FinOps began as a reaction to engineers being able to spend money faster than finance could see it. Here is how it got from there to a formal discipline that now covers SaaS, licensing and AI as well as cloud.
This article was written by Mike Wood, Development Manager at Certero, and originally published on certero.com under Joseph Lobo’s byline.
The rise of DevOps in the late 2000s set out to break down the silos between the people who wrote software and the people who ran it. It worked. Teams moved faster.
Then cloud arrived and changed the shape of the problem. Now you could move at extraordinary speed — and spend at extraordinary speed. Gone were the physical servers and the predictable, planned capital expenditure. In their place, businesses raced to adopt AWS, Azure and Google Cloud Platform. IT gained unprecedented speed and autonomy.
Two things were overlooked in the process:
This was never really about spending too much. It was about spending without governance, forecasting without accuracy, and buying without collaboration.
In the early 2010s DevOps changed how development and operations teams worked together. It introduced automation, speed and shared accountability. For a lot of us who wrote software for a living it felt like a golden age. I still remember the relief of moving to CI/CD pipelines from manual deployments and form-heavy change control — CABs and sign-offs just to push a bug fix.
But as DevOps scaled into the cloud era, it created a cost problem almost by accident:
Which led to an urgent question: how do we keep the agility of DevOps while managing costs like a business?
Some companies wanted to leave the cloud altogether — a knee-jerk reaction to not knowing how to keep financial control without going back to the old ways of working.
Enter FinOps.
FinOps — cloud financial operations — emerged as a framework to bring finance, engineering and IT together under a shared goal: cost-efficient operations without giving up speed.
The term gained traction towards the end of the 2010s. The FinOps Foundation was established in February 2019, and joined the Linux Foundation in June 2020, where it remains.
The Foundation’s definition has itself evolved, and the current wording matters more than it might first appear. As updated by its Technical Advisory Council in March 2026:
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.
Note the phrase “business value of technology”. Earlier versions of the definition were specific to “the variable spend model of the cloud”. That is no longer the boundary of the discipline, and the change is not cosmetic — it is the Foundation formally recognising that the same practice applies wherever spend is variable, decentralised and consumed before it is invoiced.
The FinOps Framework organises the work into three phases:
And, most importantly: FinOps is a team sport. Finance, engineering and product share responsibility for spend decisions. No tool fixes that part.
Once you begin reading the FinOps Framework it can be overwhelming. There is a great deal to take in, and the maturity model runs a long way past where most organisations are on day one. Do not aim for the top of it. Aim for two things you can do this quarter.
Use FOCUS cost data. The FinOps Open Cost and Usage Specification is a universal schema, which means you can finally compare like with like. A resource type Azure calls “Blob Storage” and AWS calls “S3” both normalise to a common storage category. However you prefer to do your analysis, that makes it coherent instead of disjointed. CerteroX Cloud Management ingests FOCUS through a dedicated collector and lets you query cost data against it directly, so the cost model stays portable and auditable rather than trapped in a vendor schema.
Engage with the teams. Having engineering, finance and product jointly work out where rightsizing and waste actually are is worth more than any report. Understanding what each team genuinely needs is where the larger savings come from — and it is the difference between an optimisation that sticks and one that gets reverted in a fortnight.
It helps if the recommendations are specific enough to argue with. “Potential savings identified” starts no useful conversation. “Twelve instances stopped but not deallocated, four obsolete snapshot chains, and a reserved instance you should have bought in March” starts a real one. There are 26 named checks of that kind across 12 cloud and data platforms, each with its own thresholds, pool exclusions and account skips, so the engine fits the environment rather than nagging about it. Across cloud environments under management, the average saving Certero sees is 38%.
There is room for it. 29% of cloud spend is wasted, up for the first time in five years.
FinOps was originally focused on cloud infrastructure. In recent years organisations have realised that SaaS is frequently the larger cost centre and at least as hard to manage — and, as above, the Foundation’s own definition has moved to match.
Modern FinOps practice now includes:
Each of those is a real capability rather than an ambition. CerteroX SaaS Management converges identity provider sync, 47 vendor connectors and a browser extension to find applications nobody registered, detects unused licences at 30 or more days of zero usage, and tracks upcoming renewals with days-to-renewal alongside the utilisation rate. CerteroX AI Management extends the same treatment to the newest asset class: Shadow AI detection driven by catalogue feature tags rather than a static list, per-application AI budgets, and the same 26 cost checks applied to the GPU fleets running the training workloads.
Certero holds FinOps Foundation certification on both counts — CerteroX Cloud Management is a FinOps Certified Platform, and Certero is a FinOps Certified Service Provider.
The rise of FinOps mirrors the broader evolution of IT: from siloed cost centres to business-critical functions. As organisations keep scaling in cloud and keep adding SaaS and AI tooling, FinOps stops being nice to have and becomes foundational.
Other posts covering the same ground.
Most AI spend is not arriving as new invoices. It is arriving inside software you already own, priced per token, owned by nobody. Six commercialisation patterns, why per-seat governance cannot see them, and what to do instead.
Five numbers on SaaS waste — unused licences, portfolio sprawl, dollars burned, AI spend growth and cloud waste — and why visibility alone never fixes any of them.
Salesforce instances grow wild — leavers keep their seats, admins install AppExchange packages nobody reviews, and the renewal arrives larger than anyone forecast. Where the waste actually accumulates, and the controls that stop it recurring.
Everything argued above is checkable. Name the publisher, the billing account or the platform you would argue with, and the session is built around it — the reasoning attached, not a summary slide.
No gated download at the end of it.