Introducing Continuous Cost Governance (Version 1.4)

Extending FinOps from Cost Optimization to Financial Accountability

Version: 1.4
Status: Draft for Industry Review
Date: September 2026

---

Executive Summary

Between 2019 and 2026, cloud financial management matured from an improvised practice into a recognised discipline. The FinOps Foundation's framework gave the field a shared vocabulary, a persona model, and a capability map; the FOCUS specification began to normalise billing data across providers; and the major cloud vendors embedded cost optimisation into their reference architectures. The discipline has succeeded on its own terms.

It has also moved. The State of FinOps 2026 survey of 1,192 practitioners managing more than $83 billion in annual cloud spend reports that 78% of FinOps practices now sit within the CTO or CIO organisation, while the share reporting to the CFO has fallen to 8% (FinOps Foundation, 2026a). Over the same period, the Foundation revised its mission from advancing the people who manage the value of cloud to the value of technology, and practitioners reported that scope expansion, governance, organisational alignment and forecasting now collectively outweigh optimisation as a priority. FinOps has shifted up into technology strategy and left into engineering workflow. It has not, on the evidence, shifted across into the finance control environment. (Reporting line is an imperfect proxy for control maturity — a CTO-reporting practice can maintain a strong finance liaison — but the direction of travel is unambiguous.)

That is the seam this paper examines. A technical recommendation becomes a financial result only when someone is accountable for it, someone authorises it, someone implements it, and someone independently measures what actually changed. Those steps are the ordinary substance of internal control in every other category of corporate expenditure. In consumption-based technology spend they are, in most organisations, not systematically performed — and the industry's headline metric, "potential savings," measures the absence of exactly that discipline.

This paper proposes Continuous Cost Governance (CCG): a control specification that treats each optimisation decision as a governed transaction with an owner, an evidentiary record, an authorisation, and an independently verified outcome. It is offered as an extension to FinOps, not a replacement for it, and not as an industry standard.

The paper also states plainly what CCG is not: it is not novel. Nearly every component described here already exists somewhere — in the FinOps Framework's Policy & Governance capability, in Technology Business Management, in COSO's control activities, in ITIL change enablement, in continuous controls monitoring, and in the thirty-year-old measurement and verification protocols of the energy efficiency sector. Section 4 catalogues those overlaps honestly. What appears genuinely additive is narrower than a new discipline: a specification for the object being governed, an evidentiary standard for what may be reported as a financial result, and a name for an organisational gap that recent survey data now makes visible.

---

Continuous Cost Governance in one sentence

FinOps determines what should be done with technology spend. Continuous Cost Governance establishes what was actually done, on whose authority, and what it verifiably delivered.

Key Contributions

This paper contributes three things, and claims no more:

1. A decision-centric governance model. It proposes the individual cost decision — not the period, the resource, or the service — as the unit of governance, with a defined lifecycle and a retained evidentiary record.
2. A reportability standard for realised savings. It proposes a rule separating what may be tracked operationally from what may be reported as a financial result, grounded in established measurement and verification practice.
3. A control specification that extends rather than competes with FinOps. It locates that specification inside the FinOps Framework's Policy & Governance capability, and names the organisational seam — between engineering-owned telemetry and finance-owned control — that current practice leaves unattended.

Continuous Cost Governance is abbreviated CCG throughout the remainder of this paper.

---

Who This Paper Is For

This paper is written for those with fiduciary or operational responsibility for technology expenditure:

• CFOs, controllers and finance business partners evaluating whether internal control over variable, consumption-based spending is proportionate to its materiality.
• FinOps practitioners and cloud architects whose recommendations are not converting into implemented change at the rate their analysis warrants.
• CIOs, CTOs and infrastructure executives balancing delivery velocity against budget predictability.
• Audit committees, internal audit functions and boards assessing the maturity of governance over cloud, SaaS and AI expenditure now that it rivals labour as a principal cost line in many organisations.

What This Paper Is Not

• Not an accounting or legal standard. CCG does not interpret GAAP or IFRS, does not prescribe capitalisation treatment for cloud refactoring labour, and is not legal advice. It may generate evidence useful to compliance activity; it does not constitute compliance.
• Not a replacement for FinOps. The FinOps Framework describes how to build a practice that generates and prioritises optimisation. CCG addresses what happens to an individual optimisation decision after it is generated.
• Not a claim of novelty. See Section 4.
• Not a product specification. CCG originated in observations made during the development of a commercial cost governance tool, which now operates an early, partial implementation of the loop's assignment and verification stages. That origin is disclosed here for transparency; the framework is described in vendor-neutral terms and should be evaluated independently of any implementation, and no results from that tool are cited as evidence in this paper.

---

1. The Evolution of Cloud Financial Management

The economic shift underlying this discipline is well documented. Capital expenditure on depreciating assets, governed through procurement cycles and approved in advance, was displaced by operating expenditure incurred continuously by engineers through API calls. The buyer moved from finance to engineering. The commitment moved from a signed purchase order to a running instance. Gartner forecast worldwide end-user spending on public cloud services at $723.4 billion for 2025, growing 21.5% year over year, with cloud infrastructure and platform services alone reaching approximately $301 billion (Gartner, 2024).

1.1 What FinOps Solved

FinOps emerged as a practitioner response to that shift. Its contribution is substantial and should not be understated:

• A shared language. The FinOps Framework's principles, personas, domains and capabilities gave finance and engineering a common vocabulary where none existed (FinOps Foundation, 2025a).
• Data normalisation. The FinOps Open Cost and Usage Specification (FOCUS) established a provider-neutral schema for billing data, addressing a problem that had previously consumed disproportionate practitioner effort (FinOps Foundation, 2026b).
• Decentralised accountability. The principle that "everyone takes ownership for their technology usage" moved cost consciousness into engineering teams rather than concentrating it in a central cost-control function.
• Rate optimisation at scale. Commitment-based discount instruments — reserved instances, savings plans, committed use discounts — became a managed portfolio rather than an ad hoc purchase.
• Vendor reinforcement. The AWS Well-Architected Framework elevated "Implement Cloud Financial Management" to a design principle of its Cost Optimization pillar (Amazon Web Services, 2024); Microsoft and Google published comparable guidance.

1.2 Where the Discipline Has Moved Since 2025

Two developments are material to the argument of this paper.

First, scope expanded. Framework 2025 introduced Scopes as a core element, formalising the "Cloud+" reality that practitioners were already managing SaaS, licensing, private cloud and data centre spend alongside public cloud (FinOps Foundation, 2025a). By 2026, 98% of respondents reported managing AI spend — up from 63% in 2025 and 31% in 2024 — alongside 90% for SaaS, 64% for licensing, 57% for private cloud and 48% for data centre (FinOps Foundation, 2026a).

Second, the practice moved up the technology organisation rather than into finance. The 78%/8% reporting split noted above is the clearest available signal. The Foundation's own analysis of Fortune 100 practices describes an emerging "FinOps Enabled Executive" — a VP- to EVP-level technology leader, typically with 20–25 years of engineering background, positioned as a "COO for the CTO" (Storment, 2025). This is a credible and probably correct trajectory for the discipline. It is also, unambiguously, a trajectory within the technology function.

Meanwhile practitioners report diminishing returns from the optimisation work that built the discipline. One characterised the position directly: "We have hit the 'big rocks' of waste and now face a high volume of smaller opportunities that require more effort to capture" (FinOps Foundation, 2026a). Another organisation reported reaching 97% of identified optimisation in its cost optimisation hub, with the remaining 3% deliberately not actioned for business reasons (FinOps Foundation, 2026a) — a mature outcome, and one that only means something because the organisation could distinguish actioned from identified.

No published dataset establishes how many organisations can make that distinction reliably. Practitioner testimony, including the example above, suggests many cannot; this paper treats that as a plausible and widely reported condition rather than a measured one, and Section 7 identifies closing that gap as the framework's most pressing empirical need. That gap — the unmeasured space between what tooling identifies and what an organisation can show it actually did — is the problem this paper addresses.

---

2. The Remaining Governance Challenge

2.1 Potential Savings Are Not Financial Outcomes

Cloud cost tooling is optimised to produce recommendations. A rightsizing engine surfaces an oversized instance and attaches a dollar figure. That figure is routinely aggregated across an estate, presented as "potential savings" or "cost avoidance," and reported to leadership as an achievement.

It is not an achievement. It is a hypothesis about a counterfactual. A financial outcome exists when a change is implemented, when the reduction survives comparison against a baseline adjusted for business volume and rate changes, and when the resulting figure is reflected in a budget, a forecast, or the ledger. Every step between the hypothesis and the outcome is a step where the value can be — and frequently is — lost.

The FinOps community is candid about this. The measurement problem was raised repeatedly in the 2026 survey: "Once you fix it, it's gone. How do we give developers credit for shift-left activities?" (FinOps Foundation, 2026a). The Foundation's own guidance on usage optimisation notes that estimating savings requires accounting for the full cost of change — labour hours, service disruption, transformation complexity — not merely the delta in the bill. Procurement disciplines have long distinguished realised savings from cost avoidance and tracked them separately. Cloud cost management, for the most part, has not adopted that distinction.

2.2 Why Recommendations Fail to Become Outcomes

Four mechanisms are observable, and none of them is a tooling failure.

Evidence asymmetry. A recommendation asserts a saving but rarely proves safety. The engineer receiving it bears the entire downside of a production incident and captures none of the upside of a reduced bill. Absent evidence — sustained utilisation percentiles, headroom against peak, dependency and blast-radius analysis — declining the recommendation is the individually rational choice. Recommendation volume without evidence produces fatigue, and fatigue produces silent attrition.

Ownership ambiguity. A resource tag identifies a cost centre. It does not identify a person with the authority and the standing to approve a change to a production system. Where the routing from finding to decision-maker is unreliable, findings accumulate in a queue that nobody owns.

Absent financial context. Engineers cannot reasonably assess whether a rightsizing action will drop utilisation below a committed-use threshold, alter the allocation of shared costs, or affect a unit-economic metric reported externally. That context sits in finance. In most organisations it is not consulted before the change, only after the variance.

No verification loop. Where implemented savings are never independently measured, there is no feedback signal distinguishing accurate recommendations from inaccurate ones, and no basis on which finance can rely on the number. The estimate is never falsified, so it is never improved.

Supporting evidence is directionally consistent but methodologically imperfect, and should be read with care. Flexera's State of the Cloud series reports self-estimated wasted cloud spend of 27% in 2025, rising to 29% in 2026 — the first increase in five years, attributed to AI and new service complexity (Flexera, 2026). These are respondent estimates, not audited measurements. McKinsey research based on a survey of more than 800 executives at manufacturing firms in Europe and North America found that 74% of cloud transformations failed to deliver expected savings or business value, with 40% of respondents exceeding cloud budgets (McKinsey & Company, 2021; CFO Dive, 2021). The sample limits generalisability. What these sources establish is that a gap is widely perceived; they do not establish its precise magnitude, and this paper does not assert one.

2.3 The CFO Perspective

For finance leadership the issue is not the absolute quantum of cloud waste. It is that a large, volatile, and rapidly growing expense category is being managed through a control environment materially weaker than the one applied to categories of comparable size.

Three consequences follow. Forecast reliability degrades when the inputs to the forecast include unverified savings assumptions. Internal control coverage becomes uneven: technology spend increasingly rivals labour as a principal cost line in large enterprises (Storment, 2025), yet the delegation of authority, segregation of duties and evidence retention that finance takes for granted in procurement are inconsistently applied to consumption decisions made by engineers. And fiduciary reporting weakens: a board asking whether a stated efficiency programme delivered has, in many organisations, no answer that survives scrutiny — only a dashboard of opportunities.

CFO reporting relationships in this domain declined to 8% in 2026 (FinOps Foundation, 2026a). Whatever else that number means, it does not describe a discipline moving toward the finance control environment.

2.4 Why AI Changes the Calculus

The argument above would be a modest one if consumption-based spend were stable. It is not, and the direction of change is the strongest practical case for the framework this paper proposes.

Artificial intelligence decomposes technology expenditure into a far larger population of far smaller decisions. Tokens, inference calls, embedding generation, vector database operations, GPU reservations, retrieval pipelines and increasingly autonomous agentic workloads each carry cost, and each is initiated at a level of the organisation well below where budgets are set. Where a traditional infrastructure commitment was a discrete, annual, negotiated event with a purchase order attached, an AI workload generates a continuous stream of consumption decisions with no procurement moment at all. The 2026 survey data captures how fast this arrived: 98% of practices now manage AI spend, against 63% a year earlier and 31% the year before that, and practitioners rank visibility into AI cost, allocation of that cost to business units, and determination of AI value as their three leading difficulties (FinOps Foundation, 2026a).

Three properties compound the governance problem. Pricing models are unfamiliar and vary sharply between providers, so cost cannot be inferred from architecture as reliably as it once could. Attribution is harder, because a single model endpoint may serve many business functions. And the value denominator is contested — as one practitioner put it, "Is your AI providing value? No one can answer that question yet" (FinOps Foundation, 2026a).

The consequence is directional rather than dramatic. As AI moves from experiment to material operating expense, the centre of gravity in technology financial management shifts from annual budgeting, which governs a small number of large commitments, toward continuous financial control, which must govern a large number of small ones. Periodic review scales poorly against that shape of spend. Per-decision control, applied proportionately, scales better. This paper does not claim that CCG is the only response to that shift, but the shift is what makes the response worth specifying now rather than later.

---

3. Introducing Continuous Cost Governance

3.1 Definition

Continuous Cost Governance (CCG) is a proposed control specification for consumption-based technology expenditure, in which each material cost decision is treated as a governed transaction — carrying evidence sufficient to support a decision, a named accountable owner, an authorisation proportionate to its risk and materiality, and an independently verified outcome — and in which only verified outcomes are reported as financial results.

The emphasis is deliberate. CCG does not propose new ways to find savings; that problem is well served. It proposes a specification for what happens to a finding once found, and a standard for what may be reported once acted upon.

The central term carries the weight of the framework and is defined precisely:

A governed transaction is a single cost decision that carries, as a retained record: the evidence on which it was proposed, the named party accountable for it, the financial review it received, the authority under which it was approved, declined or deferred, and the independently verified outcome it produced.

A note on scope. This paper uses public cloud examples because that is where the practice, the data and the tooling are most mature. The control specification is not cloud-specific. It applies to any expenditure that is consumption-based, initiated below the level at which budgets are set, and incurred continuously rather than at a procurement moment — which includes SaaS subscriptions, AI and inference services, data cloud platforms, and consumption-metered licensing. It is deliberately not extended in this paper to purchase-order-controlled procurement, accounts payable or ERP-mediated spend. Those categories already carry mature control environments — three-way match, purchase-order approval, established delegation of authority — and the gap this paper identifies does not exist there. Claiming them would broaden the framework's apparent reach while weakening its actual argument.

3.2 The Unit of Governance

The framework's central proposition is a change in the object being governed.

Existing disciplines govern different units. Budget governance governs the period. TBM governs the service or application. Cloud policy governance governs the resource or the configuration state. FinOps allocation governs the cost. CCG proposes governing the decision — a discrete, dated, evidenced, owned, authorised and verified event with a lifecycle and a retained record.

This is a modest-sounding shift with practical consequences. It makes optimisation auditable at the level at which decisions are actually made, it creates a denominator for measuring conversion (findings raised versus findings resolved), and it produces an evidentiary trail in the form finance and audit functions already understand.

3.3 An Honest Assessment of Prior Art

This paper was written under an explicit instruction not to manufacture novelty. Applying that test rigorously, most of CCG is not new.

Two further points of honesty are required.

The terminology is not new. "Cost governance" and "cloud cost governance" are already in general commercial use, defined by multiple vendors and analysts as continuous, policy-driven oversight of technology spend. CCG's contribution, if it has one, is not the phrase. It is the specification behind it.

The academic ground is well trodden. Continuous auditing has a formal definition dating to 1999 and a substantial peer-reviewed literature, principally associated with Vasarhelyi and colleagues at Rutgers. Anyone presenting a "continuous" governance loop to an audit committee should expect that committee to recognise the pattern immediately.

What appears genuinely additive is therefore narrow, and the paper claims no more than this:

1. The decision as the governed object, with a defined lifecycle and retained evidentiary record — a construct not specified in the FinOps Framework, in TBM, or in cloud policy governance.
2. A reportability standard that excludes estimated, potential and avoided savings from financial reporting while permitting them in operational tracking. The FinOps community identifies this measurement problem as unsolved; CCG proposes a resolution rule rather than a metric.
3. The naming of an organisational seam that 2026 survey data makes visible: continuous controls monitoring lives in finance and GRC over ERP transactions; FinOps lives in engineering over telemetry; and the space between them — consumption decisions with financial consequence, made by engineers, outside the finance control environment — has no established owner.

CCG is a recombination. Recombinations can be useful. They should not be marketed as inventions.

3.4 The Five Principles of CCG

Version 0.2 of this framework proposed seven principles. On review, those seven conflated two different kinds of statement: durable normative commitments and sequential process steps. The FinOps Framework separates Principles from Phases from Capabilities for precisely this reason, as do COSO and COBIT. Version 1.0 therefore separates them, and adds one principle that was missing.

Principle 1 — Cost decisions are governed as transactions, not as reports. The unit of governance is the individual decision, not the monthly bill or the quarterly review. A finding without a lifecycle is a suggestion.

Principle 2 — A finding must carry evidence sufficient to bear the decision it requests. The evidentiary burden sits with the party proposing the change, not the party absorbing its risk. Sufficiency scales with consequence: a sustained-utilisation percentile analysis with headroom against observed peak may suffice for a stateless workload; a tier-one transactional system warrants more.

Principle 3 — Every finding has a named accountable owner with authority to act. Ownership is a person or a defined role, derived where possible from identity systems rather than inferred from resource metadata alone. A cost centre is not an owner.

Principle 4 — Control is proportionate to materiality and risk. Governance applied uniformly to all decisions is governance that will be circumvented. Most findings should flow through lightweight, automatable paths; formal review and separated authorisation should be reserved for decisions that are financially material, operationally risky, or both. This is not merely a concession to practicality: DORA identifies "treating all changes equally" as a distinct pitfall of change approval processes, on the grounds that undifferentiated review prevents reviewers from devoting attention to the changes that actually warrant it (DORA, n.d.). This principle is the one most likely to determine whether CCG is adopted or resented.

Principle 5 — Only verified outcomes are reported as financial results. Estimated, potential and avoided savings may be tracked, and are useful operationally. They are not reported to finance, to executives, or to the board as achieved results. Verification means comparison against a baseline adjusted for business volume, rate changes and seasonality.

Crosswalk from Version 0.2. No prior content is discarded. Continuous Visibility becomes a precondition of the loop rather than a principle, because it is a data capability and is already fully specified by FinOps and FOCUS. Evidence-Based Findings becomes Principle 2. Clear Ownership becomes Principle 3. Finance Review and Human Approval become stages of the loop, governed normatively by Principles 1 and 4; "Human Approval" is renamed Authorised Change, because the salient property is authority, not the presence of a human. Verified Outcomes becomes Principle 5. Executive Accountability becomes the reporting and reallocation stage of the loop, governed by Principle 5.

3.5 The Continuous Governance Loop

The loop retains the seven-stage structure of Version 0.2, now expressed as process rather than principle, and with the exception paths made explicit — because a control with no documented rejection path is not an auditable control.

Four exception paths are first-class outcomes, not failures:

• Declined — the owner or finance rejects the change, with a recorded reason. A well-run estate will decline a meaningful share of findings; the 97%/3% example cited earlier is a mature outcome precisely because the 3% was a decision rather than a gap.
• Deferred — the change is valid but sequenced behind other work, with a review date.
• Expired — the finding received no disposition within the organisation's defined window. A deferred finding past its review date without disposition does not wait indefinitely; it is recorded as expired, with its last known state attached, and it counts against conversion. Without this rule the denominator is whatever survived attention, and the conversion metric can be improved by neglect.
• Verification failed — the change was implemented but the expected saving did not materialise. This is the most informative outcome in the loop and the one most systems discard. It is the feedback signal that improves estimate quality.

What "independent" means at stage 6. Independence is organisational separation from the decision being verified: the verifying party did not authorise the change, did not implement it, and does not own the budget it affects. In most organisations this will be a finance function or FP&A analyst distinct from the FinOps practice; in regulated environments, internal audit. Where verification is automated — a measurement pipeline comparing metered spend against an adjusted baseline — independence is satisfied by ownership of that pipeline outside the implementing team, together with an immutable record of the baseline and its adjustments. A team verifying its own savings is producing a report, not assurance, and Principle 5 does not accept it as the latter.

The loop is designed to function without infrastructure write access. CCG Core — observe, evidence, assign, review, authorise (as a recorded decision), verify, report — requires only read access to cost and telemetry data plus a system of record for decisions. An optional execution layer may automate implementation of low-risk actions or enforce policy in CI/CD, but the governance framework is complete without it. This distinction matters to conservative audit and infrastructure functions and was a deliberate design constraint.

Routing and automation. CCG does not require human review of every finding, and a reading that assumes it does will conclude, correctly, that the framework cannot scale. Principle 4 governs the loop's throughput: findings should be routed automatically according to materiality, risk classification and policy, with the substantial majority resolving through automated or lightweight paths and never reaching a review queue. Stages 3 to 5 collapse into a single automated disposition for a low-value change to a non-production resource; they remain distinct, evidenced and separately authorised for a material change to a tier-one system. What the framework requires is not that a human touches every decision, but that every decision carries a record of how it was disposed of and under what authority — including when that authority was a policy rather than a person. Automation is therefore a precondition of CCG at scale, not a departure from it. Peer review captured in the development platform satisfies stage 5 only where the review record references the governed decision: the evidence, the materiality assessment, and the delegation of authority under which the change is approved. A code review that attests to technical correctness but records nothing of financial consequence is change control, not authorisation; the framework requires the latter to be visible in the record.

3.6 The Governance Pyramid

CCG can be represented as five dependent layers, in which each layer is unreliable without the one beneath it:

1. Data — normalised cost and usage across providers and scopes; utilisation telemetry. Without this, evidence is assertion.
2. Evidence — analysis sufficient to support a decision, attached to a specific finding. Without this, ownership routes noise.
3. Control — ownership assignment, financial review, proportionate authorisation. Without this, verification measures accidents.
4. Assurance — independent verification against an adjusted baseline. Without this, reporting is estimation.
5. Accountability — executive and board reporting; reallocation of realised savings into budget or forecast.

The layered dependency is the argument for sequencing: organisations that attempt executive reporting on an unverified base produce numbers that fail on first challenge, which is the most common way credibility is lost.

3.7 The CCG Maturity Model

The FinOps Foundation's Crawl/Walk/Run model already assesses maturity across its capability set, and its caution applies here too: the objective is the appropriate level of maturity per capability, not uniform advancement (FinOps Foundation, 2025b). The model below is offered not as a replacement but as a finer-grained view of two axes — control and verification — that Crawl/Walk/Run treats only lightly.

The transition from Level 3 to Level 4 is where most of the difficulty lies, and it is organisational rather than technical: it requires finance to accept a role in a workflow it does not currently own, and engineering to accept a recorded decision point it does not currently have.

3.8 A Worked Example

Illustrative only. The figures below are synthetic. They are included to demonstrate the method and the arithmetic of verification, not to report a result. No claim is made that these values are typical.

Consider a single finding as it passes through the loop.

1 — Observe. Continuous visibility flags a production application tier: fourteen general-purpose instances, thirty-day mean CPU utilisation 11%, mean memory utilisation 24%. The cost tool attaches a naive rightsizing estimate of $24,100 annualised.

2 — Evidence. Analysis attaches to the finding a ninety-day utilisation distribution (P95 CPU 34%, P99 61%), a dependency map showing two downstream services, and the observation that the P99 peak occurs within a four-hour window on the last business day of each month, correlated with financial close. The proposed target instance size provides roughly twice the headroom against observed P99 for eleven of the fourteen instances. Three instances carry the month-end path and do not clear the threshold.

Evidence has already changed the proposal: eleven instances, not fourteen. The three excluded are recorded as Declined, with the reason attached, rather than disappearing. Revised estimate: $18,900.

3 — Assign. Resource metadata resolves to a cost centre, which is not a person. An identity lookup resolves the owning team and its engineering manager as the accountable owner. The finding is routed to a named individual with authority to act.

4 — Review. Finance identifies a second-order effect invisible to the engineering analysis: the account is substantially covered by a three-year compute commitment, and withdrawing on-demand consumption from this instance family would push utilisation of that commitment below its break-even point — transferring cost to an unused reservation rather than removing it from the P&L. Finance does not decline the change. It directs that the change be either sequenced after the commitment expires, or offset by migrating a currently uncommitted workload into the freed capacity. The team selects the offset.

This is the stage most commonly absent in practice, and in this example it is the stage that prevents a reported saving from being an accounting illusion.

5 — Authorise. The change exceeds the organisation's automatic-routing threshold on two counts — annualised value and tier-one service classification — so it does not resolve through the automated path. The accountable owner authorises it. The record captures who authorised, when, on what evidence, and what risk was accepted.

6 — Verify. Ninety days after implementation, the outcome is measured against a baseline adjusted for two exogenous changes in the period: a 6% increase in transaction volume, and a provider list-price revision.

7 — Report & Reallocate. $15,950 is reported to finance and carried into the next forecast cycle. $24,100 is not reported at any point. The gap between the two figures — roughly a third of the original estimate — is not error or waste; it is the difference between a hypothesis and a measured outcome, and under Principle 5 only the latter is a financial result.

What the example is intended to show. Four of the seven stages changed the answer. Evidence removed three instances from scope. Finance review prevented a change that would have transferred cost rather than eliminated it. Baseline adjustment removed $3,450 of apparent saving attributable to factors other than the change itself. And the decision now exists as a record that an auditor, a controller or a successor can reconstruct. The framework's value is not that it found the saving — the cost tool did that in stage 1 — but that it established which part of the saving was real.

The example above is one instance of a general pattern, shown schematically in Figure 3: each stage of the loop removes a portion of the original estimate from what may be reported, until only the verified outcome remains. The funnel contains no figures of its own — it is a shape, not a result — but it is the visual form of Principle 5: everything to the left of verification is hypothesis, and hypotheses are not financial results.

---

4. How CCG Extends FinOps and TBM

A simple division of labour describes the relationship without diminishing any of the three.

TBM provides the taxonomy — the mapping of technology cost to services, applications and business capabilities. It answers what does this cost relate to?

FinOps provides the operating practice — the culture, capabilities and analysis that generate and prioritise optimisation across an expanding set of scopes. It answers what should we do?

CCG proposes the control specification — the evidentiary, authorisation and verification requirements applied to each decision. It answers did we do it, who said so, and what did it actually deliver?

Within the FinOps Framework, CCG sits most naturally as a deepening of the Policy & Governance capability — renamed from "Cloud Policy & Governance" in Framework 2025 (FinOps Foundation, 2025a) — with dependencies on Allocation, Workload Optimization, Reporting & Analytics, and Quantify Business Value. If the FinOps Foundation were to absorb these ideas into that capability's guidance rather than as a separate framework, that would be a legitimate and arguably preferable outcome. This paper does not require CCG to exist as a distinct discipline in order for its argument to be useful.

---

5. Implications

5.1 For Finance Leaders

The practical ask is narrow: accept a defined, bounded role at stage 4 of the loop for decisions above a materiality threshold that finance itself sets. In return, finance gains a defensible realised-savings figure, an evidentiary trail in a familiar form, and an input to forecasting that has been tested rather than assumed. The threshold is the critical design choice. Set too low, finance becomes a bottleneck on trivial decisions and the process collapses. Set sensibly, the reviewed population should be small by count and large by value — the ordinary distributional logic of any materiality threshold. This paper does not propose specific figures; no published dataset supports one, and organisations should derive their own from their own finding distribution.

Who staffs stage 4. This is the most common practical question the framework raises, and it does not require a new headcount line in most organisations. Stage 4 is a review, not a build: it asks whether a proposed change interacts with a commitment, an allocation rule, or an externally reported metric — questions a FinOps analyst, a technology finance business partner, or an existing FP&A function already fields informally today. What CCG adds is not a role but a checkpoint: the review happens before implementation rather than after the variance, and it is recorded rather than remembered. Organisations already running a FinOps practice with a finance-facing capability can typically staff stage 4 from within it; the change is procedural, not organisational. Only where the reviewed population is large enough to require dedicated capacity — itself a function of the materiality threshold discussed above — does this become a staffing decision rather than a reallocation of existing review effort.

The loop's own cost should be measured, not assumed. Governance applied to a finding consumes analyst, finance and engineering time; at scale, the control has a unit cost per decision. Organisations should track cost-per-governed-decision alongside realised savings and set the materiality threshold so that the former is a small fraction of the latter. A control whose cost is unmeasured is, like the estimates it governs, a hypothesis — and Principle 5 applies to the framework's own economics as much as to the savings it reports. Where the reviewed population cannot clear that bar, the correct response is to raise the threshold, not to abandon verification.

5.2 For Engineering

The value proposition is inverted from how governance is usually presented. CCG's Principle 2 places the evidentiary burden on the party proposing the change, not the engineer absorbing its risk. Correctly implemented, it should reduce the volume of unevidenced recommendations reaching engineering queues and provide documented cover for changes that are made. Incorrectly implemented — as a universal approval gate — it will reproduce exactly the failure mode Section 6.1 describes, and engineering's objection will be correct.

5.3 For CIOs and CTOs

The 78%/8% reporting split in Section 1.2 is not only a measurement fact; it is also the shape of a political question that this paper should not pretend away. FinOps already reports into the technology organisation in most enterprises. CCG's stage 4 asks the CIO to route a defined class of decisions through a finance checkpoint before implementation — which can read, at first pass, as ceding a control point that currently sits inside technology.

The more accurate reading is the reverse. An unverified savings number is a liability in a budget conversation, not an asset: it can be, and often is, discounted or disputed by finance precisely because no one outside the technology organisation vouches for it. A verified figure, produced through a review the CIO's own organisation retains operational ownership of, is a number finance has already agreed to. That is leverage in the next budget cycle, not a loss of authority in this one. What CCG asks the CIO to give up is the unilateral right to assert a savings figure without review; what it offers in exchange is a figure finance cannot later unwind. For a function whose credibility is periodically tested by exactly that kind of dispute, the trade is favourable.

5.4 For Boards and Audit Committees

The relevant question is not "how much did we save?" but "on what basis is that figure stated?" A board-appropriate view of technology cost governance would show: findings raised and their disposition; realised savings measured against an adjusted baseline, stated separately from estimates; the population of decisions subject to formal authorisation and the exceptions to it; and the reallocation of realised savings into budget or forecast. Three or four figures, each of which can survive a follow-up question. Estimated savings, aggregate potential, and cost avoidance do not belong in that view. And there is a simple test of whether the underlying record is sufficient: internal audit should be able to re-perform the stage 6 verification from the retained record alone. If it cannot, the record is insufficient, whatever the reported figure.

Figure 5 shows the schema of that retained record: the fields each governed transaction carries from evidence through independently verified outcome, as defined in §3.2.

---

6. Limitations and Counterarguments

Intellectual honesty requires that the strongest objections be stated rather than answered pre-emptively.

6.1 The change-approval objection is evidence-based and serious

DORA's research programme has consistently found that formal change management requiring approval from an external body — a change advisory board or senior manager — is associated with worse software delivery performance. Respondents whose organisations used such processes were 2.6 times more likely to be low performers, and DORA found no evidence that a more formal external review process was associated with lower change failure rates (DORA, 2019; DORA, n.d.). DevOps practice spent fifteen years dismantling approval gates on the strength of that finding.

This paper does not dispute it. Principle 4 exists because of it. But the tension is not fully resolved, and a candid framework should say so. CCG's position is that DORA's finding concerns external approval of technical change, while CCG's stage 5 concerns authorisation of financial consequence — and that where the two coincide, peer review captured in the development platform is an acceptable authorisation mechanism, as DORA itself suggests for segregation of duties. Whether that distinction survives contact with practice is an empirical question this paper cannot settle. The practical test it implies is narrow, and worth stating: where DORA's evidence condemns external approval bodies, CCG requires none — it requires that the approval which already exists, whoever gives it, be recorded against the decision with its financial authority stated.

6.2 The materiality objection

For many organisations, cloud spend is not material to the consolidated P&L, and the governance overhead CCG proposes would not be proportionate. CCG is likely to be relevant only where technology spend is large in absolute terms, volatile, or subject to specific regulatory or margin-reporting pressure. It should not be presented as universally applicable.

6.3 The verification problem is not solved

There is no equivalent of IPMVP for cloud. Baseline adjustment for business volume, rate changes and seasonality is conceptually straightforward and practically difficult: cloud environments change continuously, attribution is contested, and the counterfactual is unobservable. Section 3.4's Principle 5 sets a standard that current methods can only partially meet. This is the framework's largest open weakness and is stated as such.

6.4 Framework proliferation

CIOs face a legitimate objection that the field does not need another framework, another maturity model and another assessment. The response offered here is that CCG is deliberately small — five principles, one loop, one reportability rule — and that its most likely useful destination is absorption into an existing framework rather than independent survival.

---

7. Future Research

Five questions would materially strengthen or falsify the propositions in this paper.

1. Conversion rate measurement. What proportion of generated recommendations are implemented, declined, deferred or silently expired, and how does that vary by evidence quality, ownership clarity and organisation size? No credible public dataset currently answers this. It is the empirical foundation the framework lacks.
2. A measurement and verification protocol for cloud. Can IPMVP's option structure and adjusted-baseline methodology be adapted to consumption-based technology spend with acceptable error bounds? What normalisation variables are required, and how should attribution be handled when multiple changes overlap?
3. The friction/realisation trade-off. At what materiality thresholds does added authorisation control begin to reduce total realised savings by suppressing implementation? This is directly testable and would resolve the tension in Section 6.1.
4. Audit utility. Do internal and external auditors regard per-decision cost governance evidence as useful, and under what circumstances would it affect testing approach or reliance?
5. AI workload economics. With 98% of practices now managing AI spend (FinOps Foundation, 2026a) and token- and inference-based pricing lacking established optimisation playbooks, does the CCG loop hold, or do decision cycles compress below the point at which per-decision authorisation is feasible? Section 2.4 argues that AI economics strengthen the case for continuous control; the opposite conclusion — that AI decision velocity defeats per-decision governance entirely — is equally testable and would falsify a central premise of this paper.

This paper is deliberately conceptual: it addresses why the control specification is needed and what it must contain. A separate companion document addressing how — data structures for the decision record, evidence sufficiency thresholds by workload class, baseline adjustment methods, and reference integrations with change and GRC systems — would be the natural next artefact, and is better written after the questions above have been tested than before.

---

8. Conclusion

FinOps solved a problem that genuinely needed solving, and continues to solve harder versions of it. Its trajectory — up into technology strategy, left into engineering workflow, out across an expanding set of technology scopes — is the right trajectory for what it is.

But that trajectory leaves a specific seam unattended. Decisions with financial consequence are made continuously, by engineers, on the basis of estimates, outside the control environment that finance applies to expenditure of comparable size. Continuous Cost Governance proposes a specification for closing that seam: govern the decision, not the report; require evidence proportionate to consequence; name an owner; authorise in proportion to risk; verify against an adjusted baseline; and report only what was verified.

Little of this is new. The components are drawn from internal control, continuous auditing, change management and energy-sector measurement and verification, and the paper has tried to say so plainly. What may be new is the assembly, the object being governed, and the discipline of refusing to report an estimate as a result.

This paper proposes the framework. It does not validate it. Validation requires the empirical work described in Section 7, and the framework should be treated as a hypothesis until that work exists.

---

References

Amazon Web Services. (2024). Cost Optimization Pillar — AWS Well-Architected Framework. https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html

Canadian Institute of Chartered Accountants & American Institute of Certified Public Accountants. (1999). Continuous Auditing. Research report. CICA/AICPA.

CFO Dive. (2021, June 8). Companies "prone to self-delusion" when using cloud, McKinsey says. https://www.cfodive.com/news/companies-prone-to-self-delusion-when-using-cloud-mckinsey-says/596505/

Committee of Sponsoring Organizations of the Treadway Commission. (2013). Internal Control — Integrated Framework. COSO.

DORA. (2019). Accelerate: State of DevOps 2019. Google Cloud / DORA. https://dora.dev/research/2019/dora-report/

DORA. (n.d.). Capabilities: Streamlining change approval. https://dora.dev/capabilities/streamlining-change-approval/

Efficiency Valuation Organization. (2018). IPMVP: Generally Accepted M&V Principles. https://evo-world.org/

FinOps Foundation. (2025a). FinOps Framework 2025. https://www.finops.org/insights/2025-finops-framework/

FinOps Foundation. (2025b). FinOps Maturity Model. https://www.finops.org/framework/maturity-model/

FinOps Foundation. (2026a). State of FinOps 2026. https://data.finops.org/

FinOps Foundation. (2026b). FinOps Open Cost and Usage Specification (FOCUS). https://focus.finops.org/

FinOps Foundation. (n.d.). Policy & Governance capability. https://www.finops.org/framework/capabilities/

Flexera. (2026). State of the Cloud Report 2026. https://info.flexera.com/CM-REPORT-State-of-the-Cloud

Gartner. (2024, November 19). Gartner forecasts worldwide public cloud end-user spending to total $723 billion in 2025 [Press release]. https://www.gartner.com/en/newsroom/press-releases/2024-11-19-gartner-forecasts-worldwide-public-cloud-end-user-spending-to-total-723-billion-dollars-in-2025

Gartner. (n.d.). Continuous controls monitoring (CCM). Gartner Information Technology Glossary. https://www.gartner.com/en/information-technology/glossary/continuous-controls-monitoring-ccm

McKinsey & Company. (2021, February 25). Clearing the air on cloud: How industrial companies can capture cloud technology's full business value. https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/clearing-the-air-on-cloud-how-industrial-companies-can-capture-cloud-technologys-full-business-value

Microsoft. (n.d.). Policy and governance — FinOps Framework. Microsoft Learn. https://learn.microsoft.com/en-us/cloud-computing/finops/framework/manage/governance

Storment, J. R. (2025, December 8). FinOps Enabled Executive: Two new archetypes for technology leadership ("COO for the CTO"). FinOps Foundation. https://www.finops.org/insights/finops-executive-technology-leader/

TBM Council. (2023). Technology Business Management Taxonomy. TBM Council.

Vasarhelyi, M. A., Alles, M. G., & Kogan, A. (2004). Principles of analytic monitoring for continuous assurance. Journal of Emerging Technologies in Accounting, 1(1), 1–21.

Weill, P., & Ross, J. W. (2004). IT Governance: How Top Performers Manage IT Decision Rights for Superior Results. Harvard Business School Press.

---

Continuous Cost Governance is a proposed framework offered for industry review and critique. It is not an industry standard. The framework originated in observations made during the development of a commercial cost governance tool; that origin is disclosed for transparency and the framework is intended to be evaluated on its own merits.