Google Cloud Organization Policy for Secure and Compliant Workloads

Overview

Organization Policy Service applies hierarchical guardrails, organization, folders, and projects, using constraints that allow or deny configurations before resources change. IAM answers who can act; organization policies answer what is permitted. Constraints encode standards: approved regions, blocked service account keys, public access prevention, and required encryption. With centralized logging and folder segmentation, policies underpin SOC 2 change management, ISO 27001 operational controls, and PCI DSS configuration hardening.

Introduction

In hundreds of projects, manual review of every API call fails. Teams enable public IPs, create keys, or deploy in the wrong regions. Platform-level prevention costs less than incident remediation.

Policies are inherited down the hierarchy. Child custom policies may tighten (or, where allowed, relax) parent rules. Folders separate production, development, and PCI cardholder environments without multiple organizations.

This post explains inheritance, enforcement at resource create and update time, a practical set of high-value constraints for regulated industries, and landing-zone implementation patterns that platform engineering teams automate with Terraform and policy-as-code pipelines.

Architecture Overview

Hierarchy: Organization → folders (BU, environment) → projects → resources.

Objects: Google-defined constraints (constraints/…); policies with boolean enforce or list allow/deny values.

Enforcement: Control plane rejects violating API calls (FAILED_PRECONDITION); Terraform plans fail in CI.

Adjacent: IAM Deny policies, VPC Service Controls, Security Command Center—org policies are baseline configuration guardrails.

Architecture Diagram

Architecture Flow Explanation

1. Org baseline: Cloud foundation sets constraints/compute.vmExternalIpAccess to deny external IPs estate-wide, documented in the constraint matrix shared with auditors.
2. Inheritance: All folders and projects inherit unless they attach a custom policy. For boolean security constraints, children are typically only allowed to be stricter—verify per constraint in Google Cloud documentation before planning folder relaxations.
3. Folder differentiation: The fde-pci folder enforces publicAccessPrevention, sql.restrictPublicIp, and iam.disableServiceAccountKeyCreation without exception. The fde-nonprod folder may allow external IPs only on tagged sandbox projects via a narrowly scoped project exception under change control.
4. API enforcement: When an engineer applies Terraform creating a Cloud SQL instance with ipv4_enabled = true in the PCI folder, the SQL Admin API returns a policy violation; the pipeline stops before production promotion.
5. Audit and SOC 2: SetOrgPolicy and folder SetPolicy appear in Admin Activity logs. An organization-level log sink with include_children = true delivers events to BigQuery in sec-logging-prod for immutable retention aligned with SOC 2 CC7.2.
6. Exceptions: Temporary relaxations use a dedicated exceptions folder, Jira ticket ID in the Terraform commit message, and automatic revert after the expiry date encoded in your policy-as-code module variables.

Core Security / Governance Best Practices

1. Terraform source of truth: google_org_policy_policy; no console drift.
2. Layered hierarchy: Org baselines; folder deltas for PCI CDE; avoid permanent project exceptions.
3. Disable SA keys: disableServiceAccountKeyCreation org-wide.
4. Domain-restricted IAM: allowedPolicyMemberDomains for Cloud Identity only.
5. Region allowlists: resourceLocations for residency and ISO 27001 geographic controls.
6. VM hardening: requireOsLogin, compute.requireShieldedVm where VMs remain.
7. No public data paths: publicAccessPrevention, sql.restrictPublicIp in regulated folders (PCI 1.2).
8. Restrict services: Limit enabled APIs in production folders.
9. Centralized logging: Pub/Sub alerts on production folder policy relaxations.
10. Least privilege admins: Central team holds policyAdmin; developers get policyViewer.

Operational Benefits

• Security architecture review boards can approve new constraints once; every new project inherits them automatically during project factory provisioning.
• Misconfigurations fail at apply time, not only in weekly scans.
• New projects inherit controls without per-team checklists.
• Audit exports map constraints to SOC 2 CC7 and ISO 27001 Annex A.
• CSPM noise drops when policies block known bad states.

Common Challenges and Mitigations

Enterprise Implementation Recommendations

• Phased landing zone, Phase 1 enables org-wide logging sinks and non-negotiable constraints (keys, public bucket access). Phase 2 retrofits existing folders after CSPM export lists violations. Phase 3 introduces automated exception workflows with expiry metadata in Terraform variables.
• Pair org policies with Resource Manager tags for chargeback and policy exceptions tied to tag keys, useful when only workloads tagged pci_scope=true require stricter storage constraints.
• PCI folder no external IPs, no keys, PAP, restricted services; optional separate billing account.
• Config Controller / ACM for GitOps policy reconciliation.
• policy-test project for negative CI tests expecting API denial.

Maintain a constraint-to-control matrix that maps each enforced policy to ISO 27001 Annex A identifiers, PCI DSS 1.2/2.2, and SOC 2 trust services criteria. Reviewers expect this during enterprise assessments.

Conclusion

Organization Policy Service turns cloud governance principles into enforced platform behavior. Org- and folder-level constraints in Terraform, plus centralized audit logging, reduce reliance on scanning alone.

Drop a query if you have any questions regarding Workload Identity and we will get back to you quickly.