How to evaluate a read-only cloud cost audit

Separate the setup administrator from the collector

Ask the supplier to identify every principal involved in onboarding and collection. The administrator who creates an application or grants a role may need privileges that the collector never needs at runtime. An export writer can also be a different identity from the application that reads the resulting files. Put each identity and its purpose into the access review.

Microsoft's export documentation describes a managed identity that writes export data to storage, including setup privileges needed to assign its role. That write operation produces the billing dataset. It does not establish that an external audit application needs permission to change VMs. Review setup actions and ongoing collector permissions independently, including any optional automation integration. [1]

Read the role definition and its scope

For each requested role, record its actions and the resource hierarchy where it applies. Azure Reader has control-plane read access and no DataActions in its published definition. It should not be interpreted as permission to read every blob or application record. Storage billing exports and directory information may require separate access, depending on the proposed workflow. [2]

Read-only access still exposes information. Resource names, tags and billing dimensions can contain project names or other sensitive business context. Ask which fields the supplier collects, which users can see them, and how retention and deletion work. Limit the approved scope to the audit's purpose. Review the full effective permission set when an identity has multiple role assignments.

Scroll the table sideways on smaller screens. Keyboard: focus the table and use the arrow keys.

Map each finding to a readable source

Ask for a source matrix before granting access. Billing records establish charges, inventory establishes observed resource configuration, and utilization metrics support workload analysis over a particular interval. A successful billing connection does not prove that the collector can read every metric required for a resize assessment. Identify the permissions that serve each requested outcome.

Vendor documentation illustrates these separate paths. Vantage distinguishes Azure cost access from resource access for recommendations and adds roles for commitments. Finout describes Storage Blob Data Reader for exports, subscription access for Advisor, and separate commitment roles. Use those instructions to identify dependencies, then request the exact configuration applicable to your agreement. Do not copy another vendor's roles into your audit by assumption. [3][4]

Inspect partial and failed results

Request an example with a missing metric and another with an inaccessible subscription. The audit should identify the affected source and scope, explain which conclusions remain supportable, and provide an authorized recovery route. A green connection indicator is too broad when billing succeeds but utilization collection fails.

Review the timestamps on a recommendation. An inventory observation collected today can be paired with metrics from an older period, but the difference must remain explicit. An empty query should retain its interval and success status without claiming continuous inactivity. If the supplier cannot show these cases in a pilot, leave evidence handling as an unresolved requirement in the access decision.

Keep approval and implementation authority explicit

Establish what happens when a reviewer accepts a finding. A read-only audit may produce instructions, an infrastructure-as-code draft or a ticket. Determine whether any separate service can execute those instructions and which additional credentials it uses. Approval inside the audit workspace should not silently expand the collector's authority.

Costframe's customer-cloud collection is read-only; the customer remains responsible for implementation. Azure is generally available, while AWS is a private pilot and Google Cloud is a private preview. Require the supported provider scope in the pilot agreement. Do not use an Azure review as evidence that the other provider integrations have equivalent permissions, detectors or operational maturity.

Document the pilot and its exit conditions

For an illustrative two-subscription pilot, record the subscription identifiers, approved billing period, credential owner and required sources. Have security approve the permission set before connection. Have engineering inspect one finding's observations and finance inspect its price basis. Record the outcome without promoting a recommendation estimate into realized savings.

Name the administrator who will revoke access at the end of the evaluation. Ask how credential rotation, failed collection and retained-data deletion are handled, and verify those procedures against your organization's requirements. Keep the final review packet with the role definitions and unresolved gaps. Continue to the provider setup documentation only after the people granting access understand the proposed collection boundary.

Related guidance