IAM policies grant permissions to identities, while organisation policies restrict which configurations can be applied to resources. IAM answers who can do something. Organisation policies answer whether a risky configuration is allowed in the first place. Used together, they separate access control from configuration control, which is essential for limiting exposure at scale.
What each policy type controls in Google Cloud
IAM policies and organisation policies solve different problems, so they are not interchangeable. IAM policies answer who can access a resource and what they can do. Organisation policies answer what configurations are allowed across a resource hierarchy, even before an identity can use them. Google Cloud’s IAM model is the access gate; organisation policy is the governance gate.
The practical difference is that IAM is identity and permission centric, while organisation policy is resource and configuration centric. An IAM binding can let a user create or edit something, but an organisation policy can still block unsafe choices such as public exposure, weak location choices, or disallowed service settings. That separation is what lets teams set guardrails without rewriting every access grant.
This distinction matters most in shared environments. If you only use IAM, you may grant the right people access and still allow unsafe deployments. If you only use organisation policy, you may constrain configurations but still leave too many identities with broad permissions. The two controls work together to reduce exposure at scale, especially when you need consistency across projects, folders, and the organisation root. For broader identity governance patterns, see IAM and IGA Basics and Lifecycle Processes for Managing NHIs.
How the two policy layers interact in practice
Think of IAM as permissioning actions and organisation policy as constraining the allowed shape of the environment. For example, IAM may allow a team to create a resource, but organisation policy may prevent that resource from being created with public IP exposure, outside approved regions, or with an unsupported feature flag. In other words, IAM decides whether the caller may act, while organisation policy decides whether the requested state is permissible.
Because organisation policy is hierarchical, it is a strong control for setting baseline guardrails that apply broadly. That makes it useful for enforcing consistency across business units, projects, and environments where local teams otherwise drift into insecure defaults. IAM remains necessary because configuration controls do not replace least privilege, delegation boundaries, or account-level accountability. The most effective deployments usually treat organisation policy as a guardrail and IAM as the access model inside that guardrail.
Practitioners often misread the two as competing controls when they are actually complementary. A good test is to ask whether the question is about entitlement or permitted configuration. If the issue is “who can create or modify this”, look at IAM. If the issue is “can this resource be configured in this risky way at all”, look at organisation policy. That separation aligns with the difference between access governance and configuration governance in IAM and IGA Basics.
Why the separation reduces risk and where teams get it wrong
The main security value of splitting these controls is blast-radius reduction. IAM limits who can take action; organisation policy limits how far a mistake, misuse, or overly generous permission can go. Together they reduce the chance that a valid identity can still create an unsafe state. Cloud governance guidance such as the CSA Cloud Controls Matrix and the NIST Cybersecurity Framework 2.0 both reinforce the value of control separation, even though they express it differently.
A common failure mode is assuming that a strong IAM review makes configuration safe. It does not. A powerful identity can still deploy insecure defaults if the organisation has not constrained the resource shape. Another failure mode is overusing organisation policy as a substitute for privilege design. That leaves too much operational power in too few hands and can create hidden exceptions that accumulate over time. When you compare the two, the real question is not which one is “stronger”; it is which control prevents the mistake you are most worried about.
For cloud environments, this distinction becomes especially important when teams use shared landing zones, templates, or automation. Central policy can stop dangerous configurations from being introduced, while IAM can ensure only the right operators or pipelines can request changes. If you also need to understand how this model affects machine or workload access patterns, the Cloud Workload Identity Guide is a useful companion for the access side of the equation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud IAM and policy separation directly maps to cloud identity control and guardrails. |
| Recommendation — Define cloud identities and restrict permissions with IAM, while enforcing baseline cloud guardrails with organisation policy. | ||
| NIST CSF 2.0 | PR.AA-05 — Least privilege is managed through identities and access to systems and assets | The question distinguishes who can act from what configurations are allowed. |
| Recommendation — Limit granted permissions to the minimum needed and review them separately from configuration guardrails. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | IAM policies are access control decisions over identities and permissions. |
| A.8.9 — Configuration management | Organisation policies restrict allowed resource configurations across the cloud environment. | |
| Recommendation — Define and enforce access rules for identities independently from configuration restrictions. Standardise and enforce secure configuration baselines across cloud resources. | ||
Practitioner Guidance
What to verify: Verify whether your control objective is about entitlement or allowed configuration before choosing the mechanism. If the answer is “who may act,” make the IAM review first. If the answer is “what may be configured,” make the organisation policy review first.
What good looks like: IAM grants are narrow, reviewed, and traceable, while organisation policies enforce non-negotiable guardrails such as approved locations, exposure limits, and disallowed resource states. Good cloud governance is visible when a permitted identity still cannot create an unsafe configuration.
Common mistake: Do not treat IAM as a substitute for baseline configuration controls, or organisation policy as a substitute for least privilege. The most reliable design uses both, with IAM managing authority and organisation policy constraining riskier states before they can be created.
Practitioner takeaway: The cleanest mental model is “IAM governs access, organisation policy governs permissible configuration”, and treating them separately is what keeps permission design from silently becoming environment design.
