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.
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.
Frequently Asked Questions
How can inherited Google Cloud IAM access be reviewed accurately?
Review iAM & Admin > Manage resources and IAM at organization, folder, and project levels and retain current evidence that 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 the evidence is incomplete or the control fails, assign an owner to move access to the narrowest practical resource, replace basic roles, and test required actions before removing the inherited grant, then retest before closure.
Why are Google Cloud Owner and Editor roles risky?
Review iAM policies across the organization, folders, and active projects and retain current evidence that 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 the evidence is incomplete or the control fails, assign an owner to replace basic roles with predefined roles, preserve at least two controlled recovery paths, and remediate service accounts using Editor before routine user cleanup, then retest before closure.
What should be checked for service account impersonation risk?
Review service account IAM policies, project IAM, and roles that include actAs or token creation and retain current evidence that 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 the evidence is incomplete or the control fails, assign an owner to remove unjustified impersonation, grant access on individual service accounts rather than an entire project, and protect more-privileged identities from less-privileged users, then retest before closure.
How should existing Google Cloud service account keys be audited?
Review iAM & Admin > Service Accounts > Keys, audit logs, CI/CD, on-premises systems, and external cloud integrations and retain current evidence that 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 the evidence is incomplete or the control fails, assign an owner to disable unused accounts before deletion, migrate viable workloads to keyless authentication, rotate necessary keys, and apply organization policy to reduce new key creation, then retest before closure.
Which Google Cloud billing permissions should be reviewed?
Review billing > Account management > Permissions and retain current evidence that 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 the evidence is incomplete or the control fails, assign an owner to separate finance, project-linking, cost analysis, and payment responsibilities, Remove stale external or former users after company-controlled replacements are tested, then retest before closure.
How can orphaned Google Cloud projects be found?
Review manage resources, Billing > My projects, project labels, and application inventory and retain current evidence that 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 the evidence is incomplete or the control fails, assign an owner to 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, then retest before closure.
What should be checked in a Google Cloud budget review?
Review billing > Budgets and alerts, notification channels, Pub/Sub connections, and Billing export and retain current evidence that capture scope, thresholds, recipients, alert delivery, owner, linked projects, export dataset, permissions, freshness, and whether management mistakes a budget for a spending cap. If the evidence is incomplete or the control fails, assign an owner to 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, then retest before closure.
Which Cloud Audit Logs matter during an IAM review?
Review logging > Logs Explorer, Audit Logs configuration, sinks, retention, and destination IAM and retain current evidence that 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 the evidence is incomplete or the control fails, assign an owner to enable required logs, correct broken sinks and broad destination access, and create actionable alerts for high-impact policy, key, project, and billing changes, then retest before closure.
How should vendor and external access to Google Cloud be reviewed?
Review iAM policies, workforce or workload identity pools, support partners, groups, and organization policy and retain current evidence that 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 the evidence is incomplete or the control fails, assign an owner to remove access without a current sponsor, narrow scopes, use controlled federation or groups, and prevent unmanaged identities from receiving new broad grants, then retest before closure.
What proves a business can recover Google Cloud administration?
Review company identity system, recovery accounts, domain control, billing contacts, organization contacts, and emergency procedures and retain current evidence that 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 the evidence is incomplete or the control fails, assign an owner to create and test company-controlled recovery before removing current access, Monitor every emergency use and require post-use review and credential protection, then retest before closure.
