Core personas are, in the FinOps Foundation's Framework, the six stakeholder groups that carry a FinOps practice: FinOps Practitioner, Engineering, Finance, Product, Procurement and Leadership; allied personas are the five neighbouring disciplines ITAM, ITFM, ITSM / ITIL, Security and Sustainability, which touch FinOps without running it. A persona, as the Foundation describes it, is a perspective rather than a position: it says what a group needs from cost data, and in a small company one person often covers several of them. In this handbook a persona also names which decision it owns. The Framework is licensed CC BY 4.0; the names stay as the Foundation writes them, as read on 2026-10-16. For the bill this means that each persona puts a different question to it, and a question nobody asks stays unanswered even when the data is there.
How it works
The Foundation describes personas as broad groups of stakeholders that have to collaborate, and gives each one objectives, areas of responsibility and contributions to FinOps. What tells one persona from another in daily work is the question it brings to the bill, the artefact it reads to answer it, and the decision that ends up with it. What FinOps is as a whole is explained in What FinOps is.
The six core personas
| Persona | Objective, as the Foundation describes it | Question to the bill | Artefact | Decision |
|---|---|---|---|---|
| FinOps Practitioner | connect business, engineering and finance and build a culture of evidence-based decisions | Are allocation, reports and cadence in place so that everyone else can decide? | allocation rule, monthly review | which savings opportunity goes into the review |
| Engineering | design and run systems that are cost-effective, performant, reliable and secure | What do my resources cost, and which of them run without benefit? | cost report per team or service | rightsizing, shutting down, architecture choice |
| Finance | quantify the business value of technology spend and carry forecasting, budgeting and chargeback | Does the invoice match budget and forecast, and how do I book it? | invoice, budget variance, allocation by cost centre | budget, showback or chargeback |
| Product | define requirements, prioritise initiatives against business goals and articulate the value of technology decisions | What does a customer, a feature, a tenant cost, and does the price carry it? | unit cost per product | prioritisation, pricing |
| Procurement | buy technology, manage contracts and vendor relationships, and time purchases with the practice | Which commitments run, when do they end, what is negotiable? | commitment overview, contract terms | commitment purchase, renewal |
| Leadership | set business and technical objectives, prioritise FinOps initiatives and promote accountability as culture | Is technology spend in proportion to growth, and who owns the variances? | overall report, budget per scope, forecast | budget envelope, investments, trade-offs |
The FinOps Practitioner is a function someone fills, not a position that has to be hired. The Foundation describes the persona through analytics, optimisation, collaboration and change management; in a company of 10 to 200 people it is filled by whoever pays or approves the invoice and also convenes the monthly review. What that looks like without a team is the subject of FinOps without a FinOps team.
The five allied personas
The allied personas do not run FinOps, but their work touches the same data. ITAM, in the Foundation's description the management of IT assets, licences and contract compliance, meets FinOps at licences and SaaS. ITFM, where it runs separately from Finance, collects and reports IT spend. ITSM / ITIL standardises IT service operations and weighs service levels against cost. Security shares transparency on usage and optimises security spend. Sustainability uses usage data for environmental goals. In a small company these are rarely roles of their own: ITAM and ITFM collapse onto the person who manages software subscriptions, Security onto the person who runs the security tooling. Which capability organises the contact with these disciplines is shown in The four FinOps domains and their capabilities.
What it means for your cost
In a company of 10 to 200 people the six core personas fall onto a few roles. The table shows which role usually carries which persona and what it has to see in the reports each month for the persona to count as filled.
| Persona | Role that usually carries it | Has to see each month |
|---|---|---|
| FinOps Practitioner | the person who pays or approves the invoice | allocation coverage, open savings opportunities, the review date |
| Engineering | the engineering lead, the team leads | cost per team or service, anomalies, idle resources |
| Finance | the same person as the Practitioner, or the external accountant | invoice against budget and forecast, allocation by cost centre |
| Product | the product lead or management | unit cost per product or customer |
| Procurement | management or the engineering lead | terms and utilisation of the commitments |
| Leadership | management | total cost against revenue and plan, budget per scope |
The distribution itself is not the problem; the Foundation explicitly allows for it in small organisations. The problem is the persona without a name. Two gaps cost money directly: Procurement, since without it nobody tracks when commitments expire and they renew or lapse without anyone having decided, and Product, since without a person who asks for unit cost the invoice stays an amount with no relation to revenue. And when Finance reads alone, the invoice is reconciled but, without Engineering, unexplained. The decision the personas drive is therefore an assignment: for each of the six questions in the first table there is a person who asks it every month, or the question stays open. How responsibilities are cut regardless of company size is covered by FinOps roles and responsibilities.
Where it goes wrong
- A persona without a person. Symptom: a commitment expires, and only the higher invoice of the following month shows it. Cause: Procurement is assigned to nobody; nobody asks about terms, although the data sits in the billing account.
- One person, all personas. Symptom: management reads the invoice, decides on commitments, judges anomalies and explains cost to engineering, all of it late. Cause: the perspectives were not separated; engineering needs a report of its own, or the Engineering persona stays unfilled even when someone is "responsible for cost".
- A persona as a job description. Symptom: the first FinOps action is a job advertisement for a FinOps Practitioner, and until the hire nobody reads the bill. Cause: the persona was confused with a position; the Foundation describes a function that, in small organisations, an existing person fills.
- Finance reads alone. Symptom: the invoice is reconciled and booked every month, but nobody can say why it rose. Cause: the cost report does not reach engineering; the Engineering persona has no artefact and therefore no question.
Sources
Read on 2026-10-16. FinOps Foundation: FinOps Personas, FinOps Framework.