How do you audit who holds the Google Cloud Project Creator Role?

What “auditing” means in Google Cloud IAM role review

Start by treating the Project Creator role as an access problem, not just a role-name lookup. The practical question is who can create projects directly, who inherits that ability through a folder or organisation binding, and whether the role is granted to a person, a group, or a service account. That distinction matters because inherited access is easy to miss if you only inspect project-level bindings.

In Google Cloud, the cleanest review path is to examine the organisation and folder hierarchy first, then list principals attached to the role at each level. If the role is granted through a group, you need to review the group’s membership separately, because the true access holders are the current members, not just the group object. NHIMG’s Google Cloud IAM and Service Accounts Guide is useful here because it covers hierarchy, role inheritance, and service account patterns in the same control plane.

This is also where scope discipline matters. A project-creation right can be perfectly legitimate for platform teams, but it should be rare outside those teams and usually tied to a clear ownership or provisioning process. If the role is being used by automation, verify that the automation has a bounded purpose and that the service account is not acting as a broad proxy for human convenience.

How to trace the actual holders, including inherited and indirect access

The most reliable audit pattern is to build the effective access picture, not just the direct assignment picture. That means checking organisation policies, folder-level IAM, and any delegated admin structure that can pass the Project Creator permission downward. If a principal appears in a broad admin or provisioning group, confirm whether that group membership is still appropriate and whether any nested groups extend access further than expected.

For service accounts, check both the role assignment and the use case. A service account may have the role because it creates projects for a controlled workflow, or it may have it because someone copied a template and never removed old privileges. The difference is operationally important, because long-lived automated access can keep project creation open long after the original business need has ended.

NHIMG’s Google Cloud Security Guide is a good companion for understanding hierarchy, org policy constraints, audit logs, and the wider controls that sit around project and folder management. If you are auditing at scale, pair the role review with inventory data so you can reconcile who has the permission with which teams are actually creating projects.

Where the role is attached to a high-level container, the review should go one level beyond the binding itself. Ask whether the binding was created for a temporary migration, a landing-zone buildout, or a permanent operating model, because temporary exceptions are often the source of stale project-creation privilege. If the rationale cannot be explained quickly, the binding deserves a closer look.

What a clean result looks like after the review

A clean result is not “no one has the role”, but “every holder has a current, documented need to create projects.” That usually means the permission is concentrated in a small number of tightly managed groups, service accounts are justified and monitored, and inherited access is understood rather than accidental. It also means the review has tested both direct grants and inherited grants, so the final answer reflects effective access instead of a partial snapshot.

Where the role is used in serverless or automation-heavy environments, watch for project creation being treated as a convenience permission rather than a governed capability. NHIMG’s Serverless Security Guide helps frame why automated execution identities need tighter scope and clearer ownership when they can change resource topology.

If you find multiple principals with the role, the next decision is whether each one is still needed or whether the capability should move behind a smaller provisioning group or approved workflow. That is especially important when billing, quota, and governance controls are tied to project creation, because unmanaged creation can spread cost and policy drift faster than teams expect.

Risk and Threat Considerations

Unnecessary Project Creator access can produce real exposure even when nobody is trying to abuse it. Excessive role distribution makes it easier to spin up projects outside normal oversight, which can fragment billing, bypass guardrails, and leave orphaned assets behind. NHIMG’s Ultimate Guide to NHIs, Regulatory and Audit Perspectives is relevant where auditability and access governance are part of the control objective.

Failure mechanism: The role is granted directly, inherited through a folder or organisation binding, or carried by group membership or a service account that no longer has a justified purpose. Because project creation is a high-leverage action, that excess access can remain invisible until new projects appear without the expected approval path.

Impact: You can end up with project sprawl, unexpected spend, weaker policy enforcement, and a larger attack surface if those projects are created faster than they are reviewed and governed.

Practitioner Guidance

What to verify: Confirm effective access, not just explicit bindings. Check who holds the role directly, who inherits it from parent containers, and whether any group or service account memberships should be trimmed immediately.

Decision rule: If the principal cannot explain a current project-creation need tied to a business or platform function, treat the permission as excess and remove or narrow it rather than keeping it “just in case”.

What good looks like: Project creation is concentrated in a small set of accountable administrators or automation identities, with documented ownership and a clear reason for every inherited grant.

Practitioner takeaway: The audit is only complete when it explains effective authority across hierarchy, groups, and automation, because that is where hidden project-creation risk usually lives.

Related resources from NHI Mgmt Group

• How do you audit who holds the Google Cloud Project IAM Admin Role?
• How do you audit who holds the Google Cloud Service Account Token Creator Role?
• How do you audit who holds the Google Cloud Service Account OpenID Connect Identity Token Creator Role?
• How do you audit who holds the Google Cloud Vertex AI Administrator Role?