How I Used GCP Privileged Access Manager to Fix a SOC 2 Duty Separation Finding
One of the most common SOC 2 findings I see on GCP platforms is standing privileged access. A developer has roles/editor on the production project. A DBA has permanent roles/cloudsql.admin. An on-call engineer was given roles/iam.securityAdmin six months ago for an incident and nobody revoked it. These aren’t edge cases — they’re the default state of most GCP platforms that weren’t built with access governance in mind from day one. And when Drata starts mapping your IAM policy to CC6.3 (logical access controls) and CC6.1 (access provisioning), standing privileged access is exactly what gets flagged.
I recently implemented GCP Privileged Access Manager (PAM) for a SaaS startup that was mid-audit with Drata and had a duty separation finding they needed to remediate before their SOC 2 Type II report closed. This post covers what PAM is, how I implemented it, what it solved, and where it fits in the broader IAM architecture I use for GCP platforms.
What GCP PAM Actually Is
GCP Privileged Access Manager is Google Cloud’s native just-in-time (JIT) access solution. It lets you replace standing privileged IAM roles with time-bound, approval-based, audited access grants — so that elevated permissions exist only for the duration of a specific task, not permanently.
The core model is built around two concepts:
Entitlements — the rules that define who can request what access, to which resource, for how long, and whether approval is required. An entitlement might say: “Members of the prod-break-glass group can request roles/cloudsql.admin on the production project, for a maximum of 2 hours, with mandatory justification and approval from a second engineer.”
Grants — an instance of an entitlement being requested and approved. When a developer needs production database access to debug an incident, they request a grant against the relevant entitlement. If approved, GCP PAM temporarily binds the role to their identity. When the grant duration expires, the binding is automatically revoked — no manual cleanup required.
The audit trail is complete: every entitlement creation, grant request, approval decision, and revocation is logged to Cloud Audit Logs and queryable in Cloud Logging. For SOC 2, this is the evidence your auditors need.
The Problem PAM Solves — In Practice
Before I implemented PAM for this client, their access model looked like this:
- 3 senior engineers had permanent
roles/editoron the production project - The lead DBA had permanent
roles/cloudsql.admin - The CI/CD service account had
roles/iam.serviceAccountAdminat the project level — broader than it needed to be - No documented justification process for elevated access
- No automatic revocation of access granted for incidents
Drata flagged this under CC6.3 — specifically the absence of controls to restrict privileged access to only what’s needed, when it’s needed, with appropriate approval and evidence.
The remediation goal was straightforward: move from standing privileges to just-in-time access for all elevated roles, with a documented approval workflow and an audit trail that maps to SOC 2 controls.
How I Implemented GCP PAM
Step 1: Enable PAM at the right scope
PAM can be enabled at the organisation, folder, or project level. For this client, I enabled it at the project level for the production project initially — giving us a contained scope to validate the entitlement model before rolling out org-wide.
Enabling PAM requires granting the PAM Service Agent the ability to make IAM policy changes on the target resource. The service agent needs getIAMPolicy and setIAMPolicy permissions at the appropriate scope — this is what allows PAM to temporarily bind and automatically revoke roles when grants are issued and expire.
If you have VPC Service Controls in place (which this client did), you also need to add the PAM service agent to the appropriate access levels or ingress rules — otherwise the service agent can’t make the IAM policy changes it needs to.
Step 2: Define the entitlement model
Before creating any entitlements, I mapped out every elevated role that had been granted as standing access, and designed an entitlement for each:
| Entitlement | Roles Granted | Max Duration | Approval Required | Justification Required |
|---|---|---|---|---|
prod-cloudsql-admin | roles/cloudsql.admin | 2 hours | Yes — 1 approver | Yes |
prod-editor-break-glass | roles/editor | 1 hour | Yes — 2 approvers | Yes |
prod-iam-admin | roles/iam.securityAdmin | 1 hour | Yes — 2 approvers | Yes |
prod-compute-admin | roles/compute.admin | 4 hours | Yes — 1 approver | Yes |
prod-logs-viewer | roles/logging.viewer | 8 hours | No — auto-approved | Yes |
The multi-party approval requirement for the most sensitive entitlements (prod-editor-break-glass, prod-iam-admin) directly addresses the insider threat and compromised approver risk — a single admin can’t approve their own elevated access request.
Step 3: Create entitlements via Terraform
Everything in Terraform. The key parameters to get right: max_request_duration sets the ceiling on how long a grant can last; approvals_needed in the approval step controls how many approvers must sign off; require_approver_justification forces approvers to document why they approved — not just click accept.
Step 4: Remove standing privileged roles
Once entitlements were in place and tested in non-prod, I removed the standing privileged role bindings from the production project IAM policy. This is the moment that matters — PAM only provides value if the standing access it replaces is actually removed.
The permanent roles the team retained: least-privilege read-only roles appropriate to their day-to-day work. The elevated roles (editor, cloudsql.admin, iam.securityAdmin) now exist only as PAM entitlements — time-bound, approval-gated, and fully audited.
Step 5: Validate the audit trail
After the first week of live operation, I exported the PAM audit logs from Cloud Logging and mapped each grant event to the corresponding SOC 2 control:
- Grant requests with justification → CC6.3 (logical access — documented business justification)
- Approver decisions with justification → CC6.3 (multi-party approval for sensitive access)
- Automatic role revocation on grant expiry → CC6.1 (access termination controls)
- Full audit log of who had what access and when → CC7 (monitoring and anomaly detection)
This gave the auditors exactly what they needed — a complete, tamper-proof record of every elevated access event, with no manual process gaps.
What PAM Doesn't Cover — And What to Do About It
PAM handles human access to GCP resources well. There are a few areas where you need complementary controls:
Service account standing access. PAM supports service account self-elevation for automated tasks, but it’s not a replacement for the Workload Identity Federation model I use for CI/CD and GKE workloads. WIF eliminates the service account key problem entirely — PAM doesn’t address that.
Broad org-level roles. PAM entitlements work at org, folder, or project scope. If someone has a standing roles/resourcemanager.organizationAdmin binding at the org level, PAM alone won’t revoke that — you need to address it in your IAM policy directly.
Data access controls. PAM controls who can assume a role temporarily — but it doesn’t control what data they can access once the role is active. VPC Service Controls handle data perimeter enforcement. PAM and VPC-SC are complementary, not overlapping.
Where PAM Fits in the Full IAM Architecture
PAM is Layer 1 (Identity) and Layer 6 (Governance) of the 6-Layer Cloud Security Model — it directly addresses identity governance and audit controls. It works alongside the broader IAM model I cover in the identity architecture work I do for GCP platforms.
The full access governance stack I implement for SOC 2 clients:
- WIF — eliminates static service account keys for workloads and CI/CD
- PAM — replaces standing privileged human access with JIT grants
- VPC Service Controls — enforces data perimeter regardless of IAM
- Cloud Audit Logs — complete audit trail for all three layers
- Org Policy constraints — prevents privilege escalation paths at the org level
No single control is sufficient. PAM closes the standing privileges gap that WIF and VPC-SC don’t address.
The SOC 2 Outcome
For the startup I implemented this for, the Drata CC6.3 finding was remediated within three weeks of PAM going live — entitlements configured, standing access removed, audit logs flowing. The auditors had evidence of an automated, documented, approval-based access process with automatic revocation. That’s exactly what the control requires.
If your Drata audit is flagging IAM access controls or you have standing privileged access you know needs to be addressed — PAM is the right GCP-native solution. It’s not complex to implement, but the entitlement model needs to be designed carefully. Getting the scope, duration, and approval chain wrong creates either too much friction for your engineering team or too little security rigour for your auditors.
Related reading:
- The 6-Layer Cloud Security Model — where PAM sits in the full security architecture
- Migrating to Keyless GCP Auth: WIF Case Study — the complementary identity control for workload access
- GCP VPC Service Controls — data perimeter controls that work alongside PAM
- Why Your Drata SOC 2 Audit Is Flagging GCP Controls — the broader SOC 2 / GCP remediation guide
- DevSecOps & Cloud Security Services — how I engage for IAM and access governance work
Dealing with a SOC 2 IAM Finding? Let's Fix It.
If Drata is flagging privileged access controls or duty separation on your GCP platform, I can identify the gaps and implement the right combination of PAM, WIF, and VPC-SC to close them — typically within 2–3 weeks.
