Billing and cost management roles are privileged access, yet most organisations hand them out like read-only reporting seats. A billing administrator can change payment details, link new projects to the corporate card, buy multi-year commitments, subscribe to marketplace software and redirect cost exports that describe the whole estate. This guide covers the identity and governance side of FinOps: who holds billing roles in AWS, Microsoft Azure and Google Cloud, how to separate viewing, budgeting, purchasing and payment rights, how to protect billing exports, and what to monitor. It is for cloud platform owners, FinOps practitioners and security teams. Runaway spend from AI agents and API loops is covered in the Denial-of-Wallet and AI Agent Cost Runaway Guide, and miner abuse in the Cryptojacking Guide; this page does not repeat them. Providers are listed alphabetically.
Key takeaways
- Billing roles are privileged roles. In each major cloud the top billing role can manage payment methods, link projects or subscriptions and grant billing access to others, so it belongs in your privileged access inventory.
- Separate the four FinOps rights. Viewing costs, managing budgets, buying commitments and paying invoices are different jobs; each cloud now offers roles or actions that let you split them.
- Purchasing rights deserve their own control. Savings Plans, reservations and marketplace subscriptions create financial commitments in seconds; deny them by default and grant them through an approved, time-limited path.
- Cost exports are sensitive data. Billing exports list every account, resource, tag and often owner email; protect the destination bucket or dataset like any other inventory of your estate.
- Monitor billing changes as security events. New billing administrators, payment method changes, new project links and unexpected commitments should alert the security team, not only finance.
Why billing access is a security problem
FinOps teams need broad visibility, and cloud providers historically made that visibility hard to grant without also granting control. The result in many estates is a small group of finance and platform staff holding owner-level billing roles, shared accounts used to download invoices, and FinOps tools connected with wide read permissions across every account. Four abuse paths follow from that:
- Unauthorised spend: an attacker or careless user links projects or subscriptions to the paying account, launches costly compute or buys commitments. The LLMjacking 2024 to 2026 case shows how stolen cloud credentials turn straight into large inference bills paid by the victim.
- Payment and invoice fraud: changes to payment methods, billing contacts or invoice delivery support fraud against the organisation and its suppliers.
- Estate reconnaissance: cost and usage data names accounts, services, regions, resource IDs and tag values. That is a ready-made map for an intruder.
- Account control: the top billing role can grant itself or others further billing roles, and in AWS the root user alone controls whether IAM principals can reach billing at all.
Billing roles by provider
The table lists each provider's own role names and what they allow, taken from provider documentation as of November 2026. Confirm current values in each provider's documentation before you build policy on them.
| Provider | Role or permission | What it allows | Treat as |
|---|---|---|---|
| AWS | Root user; "IAM User and Role Access to Billing Information" setting | Only the root user can turn on IAM access to the Billing console, per account, including every management and member account where it is wanted. Turning it on grants nothing by itself; IAM policies still decide access. | Break-glass |
| AWS | Fine-grained billing actions (for example ce:GetCostAndUsage, savingsplans:CreateSavingsPlan) and managed policies such as AWSSavingsPlansReadOnlyAccess, AWSMarketplaceRead-only and AWSMarketplaceManageSubscriptions | Split cost viewing, commitment purchase and marketplace subscription. The legacy aws-portal actions reached end of standard support in July 2023. | Privileged for purchase and payment actions; standard for read |
| Google Cloud | roles/billing.admin, roles/billing.costsManager, roles/billing.viewer, roles/billing.user, roles/billing.projectManager, roles/billing.creator | Administrator manages payment methods, exports, project links and other users' roles. Costs Manager handles budgets and cost exports without project linking. Viewer is read-only. Creator makes new self-serve billing accounts. | Admin and Creator privileged; Costs Manager elevated; Viewer standard |
| Microsoft Azure (Microsoft Customer Agreement) | Billing account owner, contributor and reader; billing profile owner, contributor and reader; invoice manager; invoice section owner, contributor and reader; Azure subscription creator | Only the billing account owner can grant billing account permissions. Billing account and profile roles inherit downward and cannot be removed at the lower scope. Invoice manager can pay invoices and create subscriptions. | Owners privileged; contributors and invoice manager elevated; readers standard |
Two provider notes matter for design. Google states that Billing Account User has very restricted permissions and can be granted broadly, while Billing Account Creator should be held by as few people as possible to prevent untracked spend. Microsoft states that inherited billing roles cannot be removed lower down, so grant at the billing profile or invoice section when a person only needs that scope.
Separating FinOps duties
The FinOps Foundation framework groups the work into domains such as Understand Usage and Cost, Quantify Business Value, Optimize Usage and Cost, and Manage the FinOps Practice. Those map neatly onto four access tiers. The tier model below is an NHI Mgmt Group recommendation, not a provider requirement.
| Tier | Typical holders | Rights | Grant method (our recommendation) |
|---|---|---|---|
| 1. View | Engineers, product owners, FinOps analysts | Read cost, usage, forecasts and recommendations for their own scope | Standing, via SSO groups, scoped to accounts, projects or invoice sections |
| 2. Budget and allocate | FinOps team, platform owners | Create budgets, alerts, anomaly monitors, cost categories and tag rules; manage exports | Standing for the FinOps team, reviewed quarterly |
| 3. Commit and subscribe | Named FinOps leads | Buy Savings Plans, reservations, committed use discounts and marketplace subscriptions | Just-in-time with approval from a second person and a ticket reference |
| 4. Pay and administer | Finance controller, cloud account owner | Payment methods, billing contacts, tax settings, billing role assignment, account closure | Two or three named holders with phishing-resistant MFA; break-glass only for the AWS root user |
- Keep tiers 3 and 4 apart: the person who buys a commitment should not also approve the payment method that settles it. That is ordinary separation of duties (NIST SP 800-53 AC-5) applied to cloud spend.
- Deny purchase actions by default: in AWS, an explicit deny on
savingsplans:CreateSavingsPlanand reservation purchase actions in a service control policy or permission boundary stops tier 1 and 2 roles from buying, whatever else they are granted. See the AWS Organizations and SCPs Guide. - Use groups, not people: assign billing roles to directory groups so joiners, movers and leavers flow through your normal lifecycle. Individual grants are how billing access outlives a role change.
- Restrict marketplace subscriptions: AWS Marketplace managed policies separate read-only, subscribe and full access. Grant the subscribe policy through a role that procurement controls, and consider a private marketplace so only approved products can be bought.
Protecting cost data and exports
Every provider can push detailed cost and usage data to storage you own: AWS Data Exports to Amazon S3, Google Cloud billing export to BigQuery, and Azure Cost Management exports to a storage account. Those destinations deserve the same controls as any sensitive dataset.
- Lock the delivery path: AWS documents a bucket policy that allows only the
bcm-data-exports.amazonaws.comservice principal to calls3:PutObject, withaws:SourceArnandaws:SourceAccountconditions tied to your account. AWS recommends disabling bucket ACLs and relying on the bucket policy. - Separate write and read: the delivery principal writes; a small set of FinOps roles and the FinOps tool read. Nobody else needs the raw files. Encrypt at rest and log data access.
- Treat FinOps tools as non-human identities: third-party cost platforms usually connect with a cross-account role, service account or app registration. Give each one read-only cost permissions, a named owner, an external ID or federated credential instead of static keys, and a review date. See the Service Account Security Guide.
- Mind tag values: tags such as owner email, cost centre or customer name flow into exports. Keep personal data out of tags or accept that the export holds it.
- Classify the dataset: cost data reveals architecture, supplier spend and growth plans. Label it at least internal and confidential where it includes customer or contract detail. See the Data Classification Guide.
Where identity fits
Most billing incidents start with an identity, not a billing feature. Three identity controls carry most of the weight:
- Root and owner accounts: the AWS root user, the person who created a Google Cloud billing account (who becomes its Administrator by default) and the Microsoft billing account owner are high-value accounts. Protect them with phishing-resistant MFA, a role mailbox rather than a personal address, and a documented recovery path. See the Break-Glass Account Guide.
- Federated, temporary access: grant billing permissions through your identity provider and short sessions, for example AWS IAM Identity Center permission sets, rather than IAM users with long-lived keys.
- Automation identities: scripts that buy commitments or move subscriptions between billing profiles are privileged machine identities. Give them narrow actions, an owner and alerting on every use.
Implementing billing access controls
- Inventory current holders: list every principal with billing roles in each provider, including inherited Microsoft billing roles, Google billing roles on the billing account and organisation, and AWS policies that include billing, Savings Plans or marketplace actions. Include FinOps tool identities.
- Classify by tier: map each holder to the four tiers above and flag anyone above the tier their job needs.
- Build the target roles: create group-based roles for each tier, with explicit denies on purchase and payment actions for tiers 1 and 2.
- Pilot with the FinOps team: move one team to the new roles first and run for a full billing cycle, checking that budgets, exports and reports still work.
- Move purchasing to just-in-time: route commitment and marketplace purchases through an approval workflow that grants tier 3 for a few hours. See the JIT Access Guide.
- Remove legacy grants: revoke the old broad roles once the new ones are proven. Keep a record of what was removed so you can roll back a specific grant within a day if a report breaks.
- Turn on alerts: wire billing role changes, payment changes and purchases into your SIEM before you declare the work done.
Choosing controls for your size
| Situation | Recommended approach (NHI Mgmt Group) | Trade-off |
|---|---|---|
| Small organisation, one cloud, finance of two or three people | Two named billing owners with phishing-resistant MFA, everyone else read-only; deny purchases outside those two | Simple, but the two owners become a dependency; document recovery |
| Mid-size, several accounts or projects, a FinOps lead | Four-tier model with groups; just-in-time for purchases; FinOps tool on a read-only federated role | Needs an approval workflow and quarterly reviews |
| Large, multi-cloud, central FinOps team and many business units | Scoped viewing per business unit (invoice section, cost category or folder), central purchasing team, policy-enforced purchase denies, billing events in the SIEM | Higher set-up effort; scope design must follow the billing hierarchy in each cloud |
Detection and measurement
Log sources: AWS CloudTrail (management events for billing, Savings Plans, Organizations and marketplace actions), Google Cloud Audit Logs on the billing account, and the Azure activity and billing logs. Alert on:
- New or changed billing role assignments, especially owner, administrator and creator roles.
- Payment method, billing contact or tax setting changes.
- New projects or subscriptions linked to a billing account outside the expected automation.
- Commitment or marketplace purchases not tied to an approved request.
- Changes to export destinations or to the export bucket or dataset policy.
Metrics that show the programme is working:
- Billing owners: number of principals with owner or administrator billing roles per provider (target: two or three).
- Standing purchase rights: principals able to buy commitments outside a just-in-time grant (target: zero).
- Unapproved purchases: commitments or subscriptions without a matching ticket in the period.
- Review coverage: percentage of billing role holders reviewed in the last quarter.
- Detection time: time from a billing role change to a security alert.
Framework mapping
| Control area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 |
|---|---|---|
| Billing role inventory and lifecycle | AC-2 Account Management | PR.AA-01 |
| Separating view, budget, purchase and payment | AC-5 Separation of Duties, AC-6 Least Privilege | PR.AA-05 |
| Owner and root account protection | AC-6(5) Privileged Accounts, IA-2(1) | PR.AA-05 |
| Billing event monitoring | AU-6, SI-4 | DE.CM-03 |
| Abuse of cloud resources for spend | SI-4 | DE.CM-03 |
In ATT&CK, unauthorised spend through stolen cloud access maps to T1078.004 Cloud Accounts for access and T1496 Resource Hijacking for impact.
Common failure patterns
- Finance on owner roles: finance staff given the top billing role because a reader role "could not download invoices", which leaves payment and role assignment rights with people who never needed them.
- Purchases with no second pair of eyes: one engineer buys a three-year commitment from a standing role; the error is found at the next invoice.
- Personal email on root or billing owner: the account owner leaves and recovery depends on a mailbox nobody controls. See the Joiner-Mover-Leaver Guide.
- Open export buckets: cost exports written to a bucket that many roles can read, so a single compromised developer role can list the whole estate.
- FinOps tool with admin rights: a cost platform connected with a broad administrator role rather than read-only billing actions, turning a SaaS supplier into a path to production.
- Budgets mistaken for limits: budget alerts notify, they do not stop spend. Pair them with identity controls and the hard limits described in the Denial-of-Wallet and AI Agent Cost Runaway Guide.
Practitioner checklist
- List every billing role holder in each provider, including inherited and group-based grants.
- Reduce owner and administrator billing roles to two or three named people with phishing-resistant MFA.
- Move the AWS root user, Google billing account creator and Microsoft billing account owner onto role mailboxes with documented recovery.
- Create view, budget, purchase and payment roles and assign them through directory groups.
- Deny commitment and marketplace purchase actions by default; grant them just in time with approval.
- Restrict export destinations to the delivery service principal and a small set of readers.
- Connect FinOps tools with read-only federated roles, each with an owner and review date.
- Alert on billing role, payment, project link, export and purchase changes.
- Review billing access quarterly and on every role change in finance or platform teams.
Standards and references
- AWS: Controlling access to the Billing and Cost Management console
- AWS: Using fine-grained AWS Billing actions
- AWS: Setting up an Amazon S3 bucket for data exports
- Google Cloud: Overview of Cloud Billing access control
- Microsoft Learn: Billing roles for Microsoft Customer Agreements
- AWS: Controlling access to AWS Marketplace subscriptions
- FinOps Foundation: FinOps Framework
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Denial-of-Wallet and AI Agent Cost Runaway Guide · Cryptojacking Guide · AWS Root Account Compromise Playbook · LLMjacking Guide