Structure GCP Organizations and Folders for Multi-Team Access (2026)

When you’re managing resources for multiple teams in Google Cloud, the structure of your Organization and Folders isn’t just about neatness; it’s the bedrock of your access control and billing.

Let’s say you have a startup that’s growing, and you’ve got engineering teams for "Frontend," "Backend," and "Data Science." You also have a "Platform" team that manages shared infrastructure. Here’s how you might set up your GCP Organization to reflect this, giving each team autonomy while maintaining central control.

your-company-org/
├── folders/
│   ├── engineering/
│   │   ├── frontend-team/
│   │   │   ├── projects/
│   │   │   │   ├── frontend-webapp-prod
│   │   │   │   └── frontend-webapp-staging
│   │   ├── backend-team/
│   │   │   ├── projects/
│   │   │   │   ├── backend-api-prod
│   │   │   │   └── backend-api-staging
│   │   └── data-science-team/
│   │       ├── projects/
│   │       │   ├── data-pipeline-prod
│   │       │   └── data-analytics-dev
│   ├── platform/
│   │   ├── projects/
│   │   │   ├── shared-vpc-host
│   │   │   └── centralized-monitoring
│   ├── shared-services/
│   │   ├── projects/
│   │   │   ├── identity-and-access-management
│   │   │   └── network-security-policies
│   ├── billing/
│   │   └── projects/
│   │       └── billing-export-project
│   └── compliance/
│       └── projects/
│           └── security-audit-logs
└── projects/
    └── central-governance-project

The key here is the hierarchy: Organization -> Folders -> Projects. Policies (like IAM roles and Organization Policies) are inherited down this tree. If you grant a role at the Folder level, all projects within that folder inherit it. This is powerful.

What Problem Does This Solve?

This structure is designed for granular access control and effective cost management. Imagine trying to give your frontend team access to only their frontend projects without this hierarchy. You’d be assigning roles project by project, a nightmare to manage as your organization scales. With folders, you grant roles/editor to the frontend-team folder, and all current and future projects within it automatically get that access for the frontend team members. Similarly, you can attach a billing account at the Organization or Folder level, ensuring all projects under it roll up to the same bill.

How It Works Internally: The Resource Hierarchy

Google Cloud resources exist in a hierarchy: Organization is the root, followed by Folders, then Projects, and finally resources like Compute Engine instances or Cloud Storage buckets. IAM policies and Organization Policies are evaluated from top to bottom.

• Organization: The highest level. You typically have one per company. This is where you set top-level policies and link your billing account.
• Folders: These are logical containers. You use them to group projects for teams, environments (prod/staging), or business units. They are crucial for organizing large numbers of projects and applying policies consistently.
• Projects: The fundamental unit for organizing resources, enabling APIs, and managing billing. Every GCP resource lives within a project.

Levers You Control

1. Folder Naming Conventions: Be consistent. team-name, environment-name, business-unit. This makes navigation and policy application intuitive.
2. Project Creation Location: When a team creates a new project, ensure they create it under the correct folder. This is often enforced with Organization Policies.
3. IAM Role Assignments: Grant roles at the highest common level. For example, give the Platform team roles/owner on the platform folder, not on each individual platform project. Grant roles/viewer to auditors at the Organization level.
4. Billing Account Links: Link your primary billing account to the Organization. You can also link specific billing accounts to Folders if you have distinct cost centers that need separate billing oversight.
5. Organization Policies: These are constraints that apply to resources within a given level of the hierarchy and below. For example, you can enforce that all resources must be deployed in a specific region using an Organization Policy applied to the engineering folder.

Consider this: if you grant the roles/browser role on the engineering folder, any user with that role can see all projects within the engineering folder, even if they don’t have explicit access to those individual projects. This is a powerful way to allow visibility without granting permissions to modify resources.

The most surprising thing is that IAM conditions can be evaluated at the folder level, not just the project level. This means you can write a condition that allows a user to be an editor on all projects within a folder unless the project name matches a certain pattern, or if the project was created before a certain date. This allows for incredibly fine-grained control without needing to manage individual project-level IAM policies for exceptions.

Once you have your Organization and Folders structured, the next challenge is managing secrets across these projects, especially for shared services.