Organization Policies and Resource Hierarchies

When you start using Google Cloud, you need a way to organise everything your company builds and runs there. Imagine you run a large retailer with teams for website, inventory, customer service, and data analytics. Each team creates virtual spaces called projects to do their work. A project in Google Cloud is a container that holds all the resources for a specific effort—things like virtual machines (virtual computers), databases, and storage buckets. Without a parent structure, every project lives on its own, and you have to set security rules separately for each one. That is time-consuming and error-prone.

Google Cloud solves this with a resource hierarchy. Think of it as a family tree or an organisational chart. At the very top is one node: the organisation node. This node represents your entire company. It is created automatically when you sign up with a Google Workspace or Cloud Identity account. Every project you create sits somewhere beneath this node.

Between the organisation node and your projects, you can create folders. Folders group projects together. Continuing the retailer example: you might have a folder called "Customer-Facing" that contains the website project and the customer-service project. You might have another folder called "Internal" that contains the inventory project and the analytics project. Folders can be nested inside other folders, so you can create a hierarchy that mirrors your company's departments, teams, or environments (development, testing, production).

Now, why does hierarchy matter for security? Because you can attach rules called organisation policies to any node in the hierarchy. An organisation policy is a set of constraints that define what is allowed or forbidden for all resources underneath that node. For example, you might create a policy that says "No one can create virtual machines outside of our approved regions." If you attach that policy to the organisation node, it applies to every project in your company. If you attach it to a specific folder, it applies only to the projects inside that folder.

This is called inheritance. Policies flow downward from parent to child. A child node (like a project) automatically gets all the policies from its parent folder, and all the policies from the folder's parent, all the way up to the organisation node. You cannot opt out of a policy set at a higher level—a developer in a project cannot override a rule set at the organisation or folder level. You can, however, make the rule stricter at a lower level. For example, if an organisation policy restricts regions to the United States, a folder could add a restriction that only a specific US state is allowed. The folder's policy is more restrictive but consistent with the parent policy.

Organisation policies are managed in the Google Cloud Console or via command-line tools. They are not firewall rules or access permissions (that is Identity and Access Management, or IAM). Instead, they are guardrails that prevent actions. For common policy types, Google provides a list of predefined constraints: for instance, "constraints/compute.requireOsLogin" forces all virtual machine access to use SSH keys rather than passwords. You can also create custom constraints using a simple language called Common Expression Language (CEL) to match your specific business rules.

The resource hierarchy also determines how IAM roles are inherited. If you grant a user a role (like Project Creator) at the organisation level, that user can create projects anywhere in the hierarchy. If you grant a role at the folder level, that user can only manage projects within that folder. This is separate from organisation policies but works alongside them.

Why was this system created? Before cloud platforms, companies owned physical servers in data centres. You enforced rules by locking doors and configuring each machine by hand. In the cloud, resources are created and destroyed on demand, and different teams may be scattered across the globe. A hierarchical policy system means you can set a baseline rule once, trust that it applies everywhere, and then empower teams to work within those boundaries without security risks.

Meet Sarah, a cloud security engineer at FinServ Ltd, a mid-sized financial services company. FinServ has three main lines of business: retail banking, wealth management, and insurance. Each line of business has its own development, testing, and production environments. Sarah's job is to enforce regulatory compliance (like GDPR and PCI DSS) without slowing down the developers.

Sarah starts by setting up the resource hierarchy. She organises the top-level organisation node, which is created when FinServ links its existing Google Workspace domain. Underneath, she creates three folders: "Retail-Banking", "Wealth-Management", and "Insurance". Inside each folder, she creates subfolders for "Dev", "Test", and "Prod". At the bottom of each subfolder, she creates the actual projects. For example, under "Retail-Banking\/Test", there is a project called "mobile-app-testing".

Now Sarah needs to enforce a policy: all production data must stay inside the European Union. She navigates to the Organisation Policies page in the Cloud Console. She finds the predefined constraint called "Resource Location Restriction" and applies it to the organisation node with a value of "europe-west1" and "europe-west4" (data centres in Belgium and the Netherlands). This means no project in the entire company can create resources outside those two regions. The policy is inherited by every folder and project.

Next, her compliance team requires that all virtual machine disks be encrypted using a company-managed key. Sarah creates a custom organisation policy using CEL that checks whether the disk creation request includes the correct customer-managed encryption key. She attaches this policy to the "Prod" subfolder inside each of the three business folders. The dev and test subfolders are not affected, so developers there can use Google-managed encryption for speed, while production must use the company's own keys.

Last week, a developer in the wealth management division created a new project directly under the organisation node, bypassing the folder structure. Sarah noticed because the audit logs showed a project creation event without a parent folder. She could have prevented this by using an organisation policy: there is a prebuilt constraint called "constraints/resourcemanager.requireFolders" that forces all projects to be created inside a folder. She enabled that policy, so now any attempt to create a standalone project is blocked with an error message.

Throughout her day, Sarah uses policy simulations to test what would happen before applying a new policy. She also uses the Policy Analyzer tool to find which resources are affected by a specific constraint. When auditors ask, "How do you ensure no resource is created outside the EU?" she points to the organisation policy applied at the root, the audit logs showing every policy change, and the simulator results. The hierarchy and policies make her job about designing the structure once, rather than fighting fires in every project.