A Google Cloud review must calculate effective access across the resource hierarchy and billing account, not simply export one project’s IAM page. Broad roles can be inherited from the organization or folder, service accounts can be impersonated, and billing authority can exist outside project administration. Every finding needs a principal, resource, role, path of inheritance, business purpose, and remediation owner.
Do not remove Owner, Editor, Service Account Token Creator, billing administration, key access, or a project link before tracing workload and recovery dependencies. Test a replacement role or identity and preserve policy plus audit evidence. Disabling a questionable service account before deletion can provide a safer observation window while keeping bindings recoverable.
ALLMSP coordinates Google Cloud access, ownership, and security review from Lawrenceville for clients in Suwanee, across Gwinnett County and Metro Atlanta, and throughout Georgia, through one accountable in-house workflow from discovery and correction through testing, training, and ongoing support.
Evidence to collect before changing Cloud IAM and billing
A useful review identifies human and non-human principals, inherited and direct roles, basic roles, service account impersonation paths, keys, external identities, billing authority, orphaned projects, budget ownership, logging coverage, and recovery gaps. Findings are ranked by reachable resources and business impact.
- Organization, folder, project, resource, service account, and billing account IAM policies.
- Effective access for Owners, Editors, administrators, external domains, groups, and service account impersonators.
- Service account purpose, attached workloads, key inventory, authentication activity, and domain-wide delegation.
- Billing account roles, payment ownership, linked projects, budgets, alerts, exports, and cost contacts.
- Cloud Audit Logs for IAM, project, billing, key, and service account changes.
- Projects outside expected hierarchy, inactive workloads, missing owners, and untested emergency access.
Calculate effective human and service account access
Organization and folder inheritance
What to check: Record direct and inherited roles, conditions, deny policies, groups, domains, and exceptions. For each broad role, identify the highest resource where it is granted and every child environment it reaches.
What to do next: Move access to the narrowest practical resource, replace basic roles, and test required actions before removing the inherited grant.
Owner and Editor roles
What to check: List every human, group, service account, domain, and external identity with Owner or Editor. Record business purpose, last activity, authentication protection, reachable production resources, and replacement role options.
What to do next: Replace basic roles with predefined roles, preserve at least two controlled recovery paths, and remediate service accounts using Editor before routine user cleanup.
Service account impersonation
What to check: Identify users and workloads that can attach, act as, or create tokens for each privileged service account. Compare the principal's own permissions with the greater access available through impersonation.
What to do next: Remove unjustified impersonation, grant access on individual service accounts rather than an entire project, and protect more-privileged identities from less-privileged users.
Review billing authority and project ownership
Service account keys and federation
What to check: Record key ID, creation date, last use where available, owner, storage, workload, rotation, and whether an attached identity, impersonation, or Workload Identity Federation could replace it.
What to do next: Disable unused accounts before deletion, migrate viable workloads to keyless authentication, rotate necessary keys, and apply organization policy to reduce new key creation.
Billing account permissions
What to check: List Billing Account Administrators, Users, Viewers, Costs Managers, payment profile owners, support contacts, and outside accounts. Record which principals can link projects, change billing settings, view cost, or manage payments.
What to do next: Separate finance, project-linking, cost analysis, and payment responsibilities. Remove stale external or former users after company-controlled replacements are tested.
Project ownership and billing links
What to check: Record every active, suspended, and pending-deletion project, billing account, environment, workload, technical owner, business owner, cost owner, and lifecycle decision. Flag projects outside the expected organization.
What to do next: Assign missing owners, move or recreate projects in the approved hierarchy when appropriate, quarantine unknown resources, and close unused projects through documented retention and recovery steps.
Budgets, alerts, and exports
What to check: Capture scope, thresholds, recipients, alert delivery, owner, linked projects, export dataset, permissions, freshness, and whether management mistakes a budget for a spending cap.
What to do next: Create missing accountable alerts, correct stale recipients, protect the export dataset, and add operational controls for services that need an actual limit or shutdown procedure.
Inspect keys, logs, and recovery paths
Audit log coverage
What to check: Confirm Admin Activity and System Event availability, required Data Access logs, IAM and billing change visibility, sink filters, destination access, retention, exclusions, and alert coverage for critical changes.
What to do next: Enable required logs, correct broken sinks and broad destination access, and create actionable alerts for high-impact policy, key, project, and billing changes.
External identities and domains
What to check: List consumer accounts, outside domains, vendors, federated subjects, dormant invitations, and groups that contain external members. Record contract owner, access purpose, resource scope, and review date.
What to do next: Remove access without a current sponsor, narrow scopes, use controlled federation or groups, and prevent unmanaged identities from receiving new broad grants.
Emergency and ownership recovery
What to check: Confirm two authorized recovery paths, strong authentication, credential custody, alerting, business approval, and a test record. Identify dependence on one employee, agency, personal account, or payment profile.
What to do next: Create and test company-controlled recovery before removing current access. Monitor every emergency use and require post-use review and credential protection.
Rank findings by reachable cloud impact
Rank access by what a principal can ultimately reach. A narrow-looking role that can impersonate a powerful service account may be more dangerous than a visible project editor. Billing loss, project deletion, production control, key creation, log tampering, and organization-level inheritance deserve immediate attention.
Priority 1: Organization, billing, or production compromise
Use this level for unknown Owners, exposed keys, unjustified privileged impersonation, payment or billing loss, suspicious project changes, disabled logging, or access that can alter production across several projects.
Priority 2: Fragile ownership and preventable privilege
Use this level for basic roles, shared default service accounts, untested recovery, one-person billing administration, unlabeled production projects, stale vendors, and key-based workloads that can move to safer authentication.
Priority 3: Governance and documentation debt
Use this level for naming, labels, missing review dates, stale viewers, incomplete budget routing, and unclassified low-risk projects after active security and continuity risks are controlled.
Official product documentation and ALLMSP resources
- Google Cloud IAM overview. Official explanation of principals, roles, resources, policies, inheritance, and fine-grained authorization in Google Cloud, with the planning steps on this page applying it to the work needed to audit Google Cloud roles, service accounts, and billing access.
- Google Cloud service-account security practices. Official guidance for limiting service-account privilege, avoiding unnecessary keys, tracking ownership, and reducing impersonation risk, with the configuration checks here applied to the controls needed to audit Google Cloud roles, service accounts, and billing access.
- Google Cloud Billing access control. Official guidance for billing-account roles, project cost access, payment-profile permissions, budgets, and administrative control, with the review process on this page using that guidance to help the organization audit Google Cloud roles, service accounts, and billing access.
Frequently Asked Questions
How can inherited Google Cloud IAM access be reviewed accurately?
Review the following systems and records: IAM & Admin > Manage resources and IAM at organization, folder, and project levels. Record direct and inherited roles, conditions, deny policies, groups, domains, and exceptions. For each broad role, identify the highest resource where it is granted and every child environment it reaches. If evidence is incomplete or a control fails, move access to the narrowest practical resource, replace basic roles, and test required actions before removing the inherited grant. Retest and document closure.
Why are Google Cloud Owner and Editor roles risky?
Review the following systems and records: IAM policies across the organization, folders, and active projects. List every human, group, service account, domain, and external identity with Owner or Editor. Record business purpose, last activity, authentication protection, reachable production resources, and replacement role options. If evidence is incomplete or a control fails, replace basic roles with predefined roles, preserve at least two controlled recovery paths, and remediate service accounts using Editor before routine user cleanup. Retest and document closure.
What should be checked for service account impersonation risk?
Review the following systems and records: Service account IAM policies, project IAM, and roles that include actAs or token creation. Identify users and workloads that can attach, act as, or create tokens for each privileged service account. Compare the principal's own permissions with the greater access available through impersonation. If evidence is incomplete or a control fails, remove unjustified impersonation, grant access on individual service accounts rather than an entire project, and protect more-privileged identities from less-privileged users. Retest and document closure.
How should existing Google Cloud service account keys be audited?
Review the following systems and records: IAM & Admin > Service Accounts > Keys, audit logs, CI/CD, on-premises systems, and external cloud integrations. Record key ID, creation date, last use where available, owner, storage, workload, rotation, and whether an attached identity, impersonation, or Workload Identity Federation could replace it. If evidence is incomplete or a control fails, disable unused accounts before deletion, migrate viable workloads to keyless authentication, rotate necessary keys, and apply organization policy to reduce new key creation. Retest and document closure.
Which Google Cloud billing permissions should be reviewed?
Review the following systems and records: Billing > Account management > Permissions. List Billing Account Administrators, Users, Viewers, Costs Managers, payment profile owners, support contacts, and outside accounts. Record which principals can link projects, change billing settings, view cost, or manage payments. If evidence is incomplete or a control fails, separate finance, project-linking, cost analysis, and payment responsibilities. Remove stale external or former users after company-controlled replacements are tested. Retest and document closure.
How can orphaned Google Cloud projects be found?
Review the following systems and records: Manage resources, Billing > My projects, project labels, and application inventory. Record every active, suspended, and pending-deletion project, billing account, environment, workload, technical owner, business owner, cost owner, and lifecycle decision. Flag projects outside the expected organization. If evidence is incomplete or a control fails, assign missing owners, move or recreate projects in the approved hierarchy when appropriate, quarantine unknown resources, and close unused projects through documented retention and recovery steps. Retest and document closure.
What should be checked in a Google Cloud budget review?
Review the following systems and records: Billing > Budgets and alerts, notification channels, Pub/Sub connections, and Billing export. Capture scope, thresholds, recipients, alert delivery, owner, linked projects, export dataset, permissions, freshness, and whether management mistakes a budget for a spending cap. If evidence is incomplete or a control fails, create missing accountable alerts, correct stale recipients, protect the export dataset, and add operational controls for services that need an actual limit or shutdown procedure. Retest and document closure.
Which Cloud Audit Logs matter during an IAM review?
Review the following systems and records: Logging > Logs Explorer, Audit Logs configuration, sinks, retention, and destination IAM. Confirm Admin Activity and System Event availability, required Data Access logs, IAM and billing change visibility, sink filters, destination access, retention, exclusions, and alert coverage for critical changes. If evidence is incomplete or a control fails, enable required logs, correct broken sinks and broad destination access, and create actionable alerts for high-impact policy, key, project, and billing changes. Retest and document closure.
How should vendor and external access to Google Cloud be reviewed?
Review the following systems and records: IAM policies, workforce or workload identity pools, support partners, groups, and organization policy. List consumer accounts, outside domains, vendors, federated subjects, dormant invitations, and groups that contain external members. Record contract owner, access purpose, resource scope, and review date. If evidence is incomplete or a control fails, remove access without a current sponsor, narrow scopes, use controlled federation or groups, and prevent unmanaged identities from receiving new broad grants. Retest and document closure.
What proves a business can recover Google Cloud administration?
Review the following systems and records: Company identity system, recovery accounts, domain control, billing contacts, organization contacts, and emergency procedures. Confirm two authorized recovery paths, strong authentication, credential custody, alerting, business approval, and a test record. Identify dependence on one employee, agency, personal account, or payment profile. If evidence is incomplete or a control fails, create and test company-controlled recovery before removing current access. Monitor every emergency use and require post-use review and credential protection. Retest and document closure.
