You’re mid-audit. Drata is connected to your GCP environment. And the dashboard is showing red.
This is one of the most common situations I get called into. A SaaS team doing everything right — building fast, shipping product, growing revenue — suddenly realizes their GCP platform wasn’t built with SOC 2 in mind. Now they have an auditor asking questions and a compliance tool flagging controls they’ve never thought about.
The good news: GCP has everything you need to pass SOC 2 Type II. The bad news: none of it is configured by default.
Here’s exactly what Drata is finding — and how to fix it.
Why GCP Fails SOC 2 Audits Out of the Box
SOC 2 is built around five Trust Services Criteria. For most SaaS companies, the relevant ones are Security (CC6), Availability (A1), and Confidentiality (C1). Drata maps your GCP configuration against these criteria and flags every gap.
The failures I see most consistently fall into four areas: IAM and access control, data encryption, audit logging, and change management. Let me walk through each one.
1. IAM and Access Control — CC6.1, CC6.2, CC6.3
This is where most GCP platforms fail first — and fail hardest.
SOC 2 CC6 requires that access to systems and data is restricted to authorized users, managed through a formal process, and regularly reviewed. What Drata typically finds in GCP:
- Static service account keys with no expiry sitting in GitHub Secrets or developer machines
- Service accounts with editor or owner roles at the project level — far broader than any workload needs
- No evidence of access reviews — Drata needs to see that permissions are reviewed periodically, not just granted once
- No separation of duties — the same identity that deploys code can also modify IAM policies
The fixes:
- Replace static service account keys with Workload Identity Federation — this eliminates the entire class of credential leakage risk that CC6.1 is designed to catch
- Apply least-privilege IAM bindings at the resource level, not the project level — every service account should have exactly the permissions it needs and nothing more
- Implement duty separation — the identity that deploys to production should not be the same identity that can modify infrastructure or IAM. This is a hard requirement for SOC 2 and one of the most commonly missed on GCP
- Document and schedule access reviews — Drata can automate evidence collection but someone needs to own the review process
The broader identity architecture — how you structure IAM across org, folders, and projects — is covered in the 6-Layer Cloud Security Model. Layer 1 (Identity) is almost always the first thing I fix in a SOC 2 engagement.
2. Data Encryption — CC6.1, C1.1
SOC 2 requires that sensitive data is protected at rest and in transit. GCP encrypts data at rest by default using Google-managed keys — but Drata and most auditors want more than that for a SOC 2 Type II report.
What Drata flags:
- No Customer-Managed Encryption Keys (CMEK) for sensitive data stores — Cloud SQL, GCS buckets, GKE etcd
- Secrets stored as environment variables or in Kubernetes Secrets without application-layer encryption
- No evidence that encryption is enforced by policy, not just assumed
The fixes:
- Enable CMEK via Cloud KMS for Cloud SQL databases, GCS buckets containing sensitive data, and GKE cluster secrets. This gives you auditable key management and the ability to prove encryption is enforced
- Move application secrets to Secret Manager and use the CSI Driver or External Secrets Operator to inject them into workloads — never environment variables, never raw Kubernetes Secrets
- Enforce HTTPS-only access on all Cloud Run services and load balancers — transit encryption needs to be enforced by configuration, not convention
- Apply org policies to deny object ACLs on GCS buckets and enforce uniform bucket-level access — this prevents accidental public exposure of sensitive data
3. Audit Logging — CC7.2, CC7.3
SOC 2 CC7 requires that you can detect, respond to, and investigate security events. Drata checks whether your logging is comprehensive enough to support that.
What Drata flags:
- Data Access audit logs not enabled — by default GCP only logs Admin Activity. Data Access logs (who read what data, when) are off by default and must be explicitly enabled
- No log retention policy — audit logs need to be retained for a minimum period to satisfy SOC 2 evidence requirements
- No alerting on suspicious activity — logs exist but no one is watching them
- VPC Flow Logs disabled — network-level visibility is often missing entirely
The fixes:
- Enable Data Access audit logs for all critical services — Cloud SQL, GCS, Secret Manager, IAM, GKE. Do this at the org level so it applies to all current and future projects
- Configure a Cloud Logging sink to export logs to a GCS bucket with a 12-month retention policy — this satisfies auditor evidence retention requirements
- Set up log-based alerts for high-risk events: IAM policy changes, service account key creation, project-level permission grants, public access changes on GCS buckets
- Enable VPC Flow Logs on all subnets handling sensitive traffic — this is increasingly expected by SOC 2 auditors for network monitoring evidence
4. Change Management — CC8.1
CC8 requires that changes to production systems go through a controlled, documented process. This is where GCP platforms built by fast-moving engineering teams most commonly fail.
What Drata flags:
- No evidence that infrastructure changes are reviewed before being applied — manual terraform apply by individuals with no PR review
- Container images deployed to production without signing or verification — anyone with push access can deploy anything
- No separation between build and deploy — the same pipeline that builds code also has permissions to modify infrastructure
The fixes:
- All infrastructure changes through Terraform via CI/CD pipelines with mandatory PR review — no manual CLI changes to production. Every change is tracked in Git, reviewed by a human, and applied by a pipeline
- Enable Binary Authorization on GKE — only container images signed by your trusted CI/CD pipeline can be deployed to production. This gives auditors cryptographic evidence that your change management process was followed for every production deployment
- Separate build permissions from deploy permissions — the service account that builds images should not have the ability to modify cluster configuration or IAM policies
The Pattern I See Every Time
When I review a GCP platform that’s failing Drata checks, the root cause is almost never a single missing control. It’s a platform that was built for speed without a security architecture underneath it.
Drata can tell you what’s failing. What it can’t tell you is how all the failures connect — and why fixing one without understanding the others leaves you exposed.
The 6-Layer Cloud Security Model is the framework I use to make sure every SOC 2 control has a deliberate architectural home — not just a checkbox. And the SCALE Framework is how I ensure the fixes we make are durable, not just audit-passing.
If you want to understand how I approach DevSecOps as a complete platform discipline — not just SOC 2 compliance — the DevSecOps & Cloud Security service page covers the full engagement model.
Mid-Audit? Here's Where to Start
If you’re mid-audit right now, prioritize in this order:
Priority | Area | First action |
1 | IAM / Access Control | Audit service account permissions, remove static keys, implement WIF |
2 | Audit Logging | Enable Data Access logs at org level, set up log sink with retention |
3 | Data Encryption | Enable CMEK for critical data stores, move secrets to Secret Manager |
4 | Change Management | Enforce Terraform-only infra changes via CI/CD, enable Binary Authorization |
IAM first — always. It’s the fastest to fix, the most commonly flagged, and the one auditors look at first.
Mid-audit with Drata and GCP controls flagging red?
I can usually identify the root cause and a remediation path in a single call. Book a free GCP architecture consultation and we’ll work through exactly what Drata is flagging and why.
