Cloud billing permissions decide who can sign multi-year commitments, change payment methods and export detailed cost data, yet they are often granted by whoever set up the billing account and never reviewed. This template gives you a ready-to-use access control matrix for FinOps: who can view, allocate, buy, export, pay and administer, with approval rules and a review cycle. It is written for FinOps leads, cloud platform owners, finance controllers and IAM teams who need a documented, auditable record of billing access. It is the companion artefact to our FinOps Security, which explains why billing access is a security problem and the four-tier model this matrix builds on. Cloud providers are listed alphabetically; order is not a ranking.
This is an independent template from NHI Mgmt Group, based on AWS, Google Cloud and Microsoft public documentation as of November 2026. It is not sponsored or reviewed by any of them. Role names change, so confirm them against each provider's current documentation.
How to use this template
- Replace placeholders: change text in square brackets, such as [Organisation], [FinOps lead] and [Finance controller], to your own names and groups.
- Fill the matrix per billing scope: one copy per billing account, organisation or billing profile if duties differ between them. Small organisations can keep one copy.
- Map to provider roles: use section 5 to translate each tier into your provider's own role names, then confirm current role definitions in the provider's documentation, because role names and permissions change.
- Keep it live: store the completed matrix with your access review evidence and update it whenever a role, group or tool changes.
- Recommendations are ours: the tier model, approval thresholds and review frequencies below are NHI Mgmt Group recommendations, not provider requirements. Adjust them to your risk appetite.
1. Purpose and scope
1.1 This matrix defines who in [Organisation] may perform each billing, cost management and commitment action across [list cloud providers and marketplaces in scope].
1.2 It applies to people, groups, service accounts, workload identities and third-party FinOps tools with any access to billing accounts, cost data, commitment purchases, marketplace subscriptions or payment settings.
1.3 It is owned by [FinOps lead] and approved by [Finance controller] and [Head of Cloud Security]. It is reviewed every [six] months and after any reorganisation of billing accounts.
2. Roles
2.1 The roles below follow the FinOps Foundation's personas (FinOps Practitioner, Engineering, Finance, Leadership, Procurement and Product, with Security as an allied persona), plus the identities that automate FinOps work.
| Role in this matrix | Typical holder | Directory group (fill in) |
|---|---|---|
| Engineer / product owner | Engineering and product teams viewing their own spend | [grp-finops-view-team-x] |
| FinOps analyst | FinOps practitioners producing reports, budgets and allocations | [grp-finops-analyst] |
| FinOps lead | Named practitioners who recommend and execute commitments | [grp-finops-commit] |
| Procurement | Marketplace and contract owners | [grp-procurement-cloud] |
| Finance controller | Pays invoices, owns payment methods and tax settings | [grp-finance-billing-admin] |
| Cloud platform administrator | Owns account, project and subscription structure | [grp-cloud-platform-admin] |
| Security and audit | Reviews access and investigates anomalies | [grp-sec-billing-read] |
| FinOps automation identity | Service accounts or roles used by export pipelines and FinOps tools | [svc-finops-export], [role-finops-tool-read] |
3. Access tiers and grant rules
| Tier | Covers | Grant method |
|---|---|---|
| T1 View | Read cost, usage, forecasts and recommendations for an assigned scope | Standing, through SSO group, scoped to own accounts, projects or invoice sections |
| T2 Allocate | Budgets, alerts, anomaly monitors, cost categories, tag rules, exports configuration | Standing for FinOps analysts, reviewed every [three] months |
| T3 Commit | Savings plans, reservations, committed use discounts, marketplace subscriptions, new subscriptions or billing accounts | Just-in-time elevation with second-person approval and a ticket reference |
| T4 Administer | Payment methods, billing contacts, tax settings, billing role assignment, account closure | [Two or three] named holders, phishing-resistant MFA, no standing use of break-glass accounts |
4. The access control matrix
4.1 Key: A = allowed (standing); J = allowed through just-in-time elevation with approval; P = approves, does not execute; R = read only; X = denied (enforce with a deny policy where the provider supports one).
| Action | Engineer / product | FinOps analyst | FinOps lead | Procurement | Finance controller | Platform admin | Security / audit | Automation identity |
|---|---|---|---|---|---|---|---|---|
| View cost and usage for own scope | A | A | A | A | A | A | R | R |
| View cost for whole billing account | X | A | A | R | A | R | R | R |
| View negotiated or custom pricing | X | X | A | A | A | X | R | X |
| Create and edit budgets and alerts | X | A | A | X | A | X | X | X |
| Configure anomaly detection | X | A | A | X | X | X | R | X |
| Manage cost allocation and tag rules | X | A | A | X | X | A | X | X |
| Create or change cost data exports | X | J | A | X | X | X | R | X |
| Read exported cost data | X | A | A | X | A | X | R | A |
| Purchase commitments (savings plans, reservations, committed use) | X | X | J | X | P | X | X | X |
| Subscribe to marketplace products | X | X | X | J | P | X | X | X |
| Create billing accounts or billing profiles | X | X | X | X | J | P | X | X |
| Link or unlink projects and subscriptions to billing | X | X | X | X | X | A | X | X |
| Manage payment methods and tax settings | X | X | X | X | A | X | X | X |
| Pay invoices | X | X | X | X | A | X | X | X |
| Assign billing roles to others | X | X | X | X | J | P | R | X |
| Close or transfer billing accounts | X | X | X | X | J | J | X | X |
4.2 No person may both execute and approve the same T3 or T4 action. Where the matrix shows J for one role and P for another, the approver must be a different individual from the requester.
4.3 Any cell changed from this baseline is recorded as an exception in section 7 with an owner and expiry date.
5. Provider role mapping
5.1 Fill in the role or permission set used for each tier. The examples are taken from provider documentation as of November 2026 (AWS: Controlling access to Billing and Cost Management, Google Cloud: Overview of Cloud Billing access control, Microsoft Learn: Billing roles for Microsoft Customer Agreements); confirm current definitions before relying on them.
| Tier | AWS | Google Cloud | Microsoft Azure (Microsoft Customer Agreement) |
|---|---|---|---|
| Prerequisite | The root user turns on "IAM User and Role Access to Billing Information" in each account that needs it; IAM policies then decide access | Our recommendation: grant at billing account or project level rather than organisation level, because Google documents that organisation-level policies are inherited by all billing accounts and projects beneath them | Grant at the lowest scope needed; billing account roles inherit to billing profiles and invoice sections and cannot be removed lower down |
| T1 View | [Customer-managed policy with read-only Cost Explorer and billing actions] | roles/billing.viewer, or roles/billing.projectCostsManager with project cost view permissions for scoped access | Billing account reader, billing profile reader or invoice section reader |
| T2 Allocate | [Policy allowing budgets, cost categories, anomaly monitors and exports] | roles/billing.costsManager (budgets and cost exports, no pricing data or project linking) | Billing profile contributor for budgets at that scope [confirm fit] |
| T3 Commit | [Role allowing Savings Plans and reservation purchase actions, assumed just in time] | [Role used for committed use discount purchases, elevated just in time] | Invoice section contributor or Azure subscription creator for new subscriptions; [role for reservation purchases] |
| T4 Administer | [Billing administration policy; root user kept for break-glass only] | roles/billing.admin; roles/billing.creator held by as few people as possible | Billing account owner or billing profile owner; invoice manager for paying invoices |
5.2 Assign every provider role to a directory group, never to an individual user, so joiner, mover and leaver changes flow through normal lifecycle processes.
6. Approval and segregation rules
6.1 Commitment purchases above [amount or term, for example any commitment longer than 12 months or above 10,000 per month] need approval from [Finance controller] and [FinOps lead], recorded in [ticketing system].
6.2 Marketplace subscriptions are requested by [Procurement] and approved by [Finance controller]. Where the provider offers a private catalogue of approved products, only approved products may be subscribed.
6.3 Changes to payment methods, billing contacts or billing role assignments need a second person to confirm through a separate channel before they take effect.
6.4 Break-glass billing accounts, including the AWS root user, are vaulted, protected with phishing-resistant MFA and used only under the [break-glass procedure].
7. Non-human access and FinOps tools
7.1 Each automation identity is listed here with its owner, scope, credential type and expiry.
| Identity | Purpose | Owner | Tier and scope | Credential type | Review date |
|---|---|---|---|---|---|
| [svc-finops-export] | Delivers cost exports to [storage] | [FinOps lead] | T1, [billing account] | [Provider-managed service identity / federated workload identity] | [date] |
| [role-finops-tool-read] | Third-party FinOps platform reads cost data | [FinOps lead] | T1, [scope] | [Cross-account role with external ID / federated identity] | [date] |
| [svc-commitment-automation] | Automated commitment purchasing, if used | [FinOps lead] | T3, capped at [amount] | [Short-lived token, approval gate] | [date] |
7.2 Third-party tools get read-only access unless a documented business case approves more. Prefer federation or provider-managed identities over long-lived access keys. See the Cross-Account and Cross-Tenant Access Guide and the Workload Identity Federation Guide.
7.3 Destinations holding exported cost data are treated as confidential: restricted bucket or dataset policies, logging of reads, and no public access.
8. Review, monitoring and exceptions
8.1 [Security / audit] reviews billing role assignments against this matrix every [three] months for T3 and T4 and every [six] months for T1 and T2, using the Access Reviews Guide process.
8.2 Alerts are raised for: new billing role assignments, commitment and marketplace purchases, payment method changes, new or changed exports, and use of break-glass accounts. See the Cloud Cost Anomalies as Security Signals guide for spend-based signals.
8.3 Exceptions are recorded with requester, cell changed, reason, compensating controls, approver and expiry no later than [90 days].
| Exception ID | Identity or group | Matrix cell changed | Reason | Approver | Expiry |
|---|---|---|---|---|---|
| [FIN-EXC-001] | [name] | [action / role, X to A] | [reason] | [name] | [date] |
Implementation guidance
- Export current assignments: list every billing role assignment in each provider, including legacy project-level roles that confer billing rights (Google notes that Project Owner is a superset of Project Billing Manager).
- Compare with the matrix: mark each assignment as matching, over-privileged or unknown owner. Unknown owners go to [FinOps lead] for resolution within [30 days].
- Move to groups: recreate assignments as group grants, then remove individual grants after a [two-week] overlap.
- Introduce just-in-time for T3: pilot with one FinOps lead and one billing scope, confirm purchases still complete, then extend. Roll back by restoring the standing group grant if elevation blocks an urgent purchase.
- Add deny guardrails: where the provider supports organisation-level deny policies, deny purchase actions to every role outside T3.
- Measure: track the number of T3 and T4 holders, the share of grants made to groups rather than individuals, purchases with a linked approval, and open exceptions past expiry.
Small organisations can merge roles (for example, FinOps lead and finance controller may be one person) as long as T3 purchases still have a second approver. Large organisations should keep one matrix per business unit and report deviations to the risk committee. For the identity controls behind each tier, see the Privileged Access Management Guide and the JIT Access Guide.
Related NHI Mgmt Group resources: FinOps Security · Cloud Cost Anomalies as Security Signals · Access Reviews Guide · JIT Access Guide