GCP Security Baseline: IAM, Logging, Network, and Storage Controls

Run gcloud projects list against an organisation that has been going for three years and count how many projects you can name an owner for. In most environments the answer is somewhere under half. That number, more than any scanner finding, tells you what state the security posture is in — because every control below depends on someone being accountable for the thing it applies to, and an unowned project is one nobody will fix, nobody will decommission, and nobody will notice going public.

GCP environments get hard to secure through ordinary growth, not sophisticated attacks. Projects, service accounts, firewall rules and buckets appear at the speed of engineering; governance arrives afterwards, if it arrives. The result is predictable: privilege sprawl, partial visibility, and exposure nobody chose.

A baseline is the minimum every project must meet before it scales further. It is not a target architecture and it will not make you secure. It sets a floor, so that the worst project in your estate is merely adequate rather than unknown.

GCP security baseline

Use this as an implementation framework for an internal cloud hardening programme.

1) Why a baseline needs to exist before cloud scale, not after

Waiting until a GCP environment is large and complex to define baseline controls creates a much harder problem. Here’s what you’re preventing by establishing the baseline early:

Project sprawl without clear ownership or consistent tagging
Broad IAM grants that made sense at the time and then never got narrowed
Audit logs that weren’t enabled before an incident that required them
Network exposure that accumulated one firewall rule at a time
Inconsistent control expectations that engineering teams can’t meet because nobody defined them

Two of those are worse than they look. Audit logs that weren’t enabled before an incident cannot be retrofitted — Data Access logs are not retroactive, so if they were off during the window you care about, that period is simply gone and your investigation becomes inference. And an IAM grant that made sense at the time is nearly impossible to remove later, because nobody can prove what still depends on it.

The honest cost side: a baseline does constrain engineering, whatever the framing. Default-deny egress breaks things. Organisation policy constraints block deployments that used to work. What a baseline buys is that the friction arrives at design time, in a form a team can plan around, rather than at 2 a.m. in a form nobody can.

2) The domains you need to standardize first

Teams that try to build the whole programme at once end up with a long backlog of half-implemented controls, which is worse than a short list of finished ones — a control that is 60% deployed gives you the reporting burden without the protection. Establish these domains in roughly this order, identity and logging before broad workload rollout:

Organisation and project hierarchy design
IAM roles, groups, and service account governance
MFA and identity assurance for privileged users
Cloud Audit Logs configuration and retention strategy
VPC firewall rules and network segmentation
Cloud Storage exposure and access control
Public exposure detection and remediation workflows
Secret handling and key management hygiene
Compute and container hardening essentials
Billing alerts and cost anomaly monitoring as a security signal

Reverse that order and risk accumulates faster than governance can catch it. The specific failure is that identity and logging are the two domains that are painful to retrofit: narrowing an IAM grant after workloads depend on it requires proving a negative, and log coverage you turn on today tells you nothing about last month.

3) GCP baseline checklist — use this as a recurring governance artifact

Baseline Control Area	Minimum Standard	Validation Method	Owner
Organisation Structure	Projects grouped by environment and business function with clear ownership	Org/project inventory review	Cloud platform owner
IAM Role Design	Least-privilege roles; no unnecessary Owner-level assignments	IAM bindings audit	IAM/security team
Service Accounts	Dedicated service accounts per workload with scoped permissions	Service account inventory + policy review	Platform engineering
MFA Enforcement	MFA required for all privileged access paths	Identity policy verification	Identity admin
Cloud Audit Logs	Admin activity and data-access logs enabled at appropriate scope	Logging policy and sink checks	Security operations
VPC Firewall Rules	Ingress and egress aligned to approved services only	Firewall rule audit + change review	Network/cloud ops
Cloud Storage Security	Buckets private by default with documented explicit exceptions	Bucket ACL/IAM policy scan	Data/platform owner
Public Exposure Control	External endpoints inventoried and reviewed with named owners	Exposure report + owner confirmation	Cloud security
Secrets Management	No secrets in code or environment variables where avoidable; managed storage used	CI scan + config review	DevSecOps
Compute Hardening	Baseline images, patch process, and metadata protections in place	Image/policy compliance checks	Compute owner
Container Security	Workload identity, least privilege, and image scanning controls active	Cluster and CI policy checks	Kubernetes/platform team
Billing and Alerting	Budget alerts and anomaly monitoring enabled across projects	Billing config review	FinOps + security

A note on the Data Access half of the audit-log row, because it is the one control here with a bill attached: Admin Activity logs are enabled by default and free, but Data Access logs are opt-in and charged by volume, and on a busy project they can generate more log data than the workload generates traffic. Turning them on organisation-wide without scoping is how teams end up with a logging invoice that gets the control switched off again three months later. Enable them where the data justifies it, and decide that scope deliberately rather than discovering it on a bill.

This table belongs in your governance review cadence, not just in onboarding documentation.

4) Practical risk prioritization — not all gaps are equal

When you’re looking at a gap register with dozens of findings, you need a way to decide what to fix first. Prioritise by the combination of exposure, privilege level, and potential business impact.

Highest-priority risk categories

Public exposure with weak or absent access controls
Privileged identities with broad or unmanaged access
Missing or incomplete audit logging before it’s needed
Unmanaged service account keys and stale credentials sitting in automation
Overly permissive firewall rules that opened for a reason and never closed

Risk Pattern	Likelihood	Business Impact	Priority
Public bucket with sensitive data potential	High	High	Critical
Excessive Owner role usage across projects	Medium-High	High	High
Missing audit logs for privileged actions	Medium	High	High
Stale service account keys in automation	Medium	Medium-High	High
Broad firewall ingress on non-public services	Medium	High	High
Project naming/ownership inconsistency	High	Medium	Medium

If two or more high-priority risks coexist in a production environment, treat baseline remediation as an urgent programme with dedicated resources — not a background task competing with feature work.

5) Tooling workflow for baseline assessments

Use tooling for visibility and repeatability, then validate by hand before changing anything. Automated tools surface findings fast and are confidently wrong about a meaningful fraction of them — a “publicly exposed” bucket that fronts a static site, a “stale” service account that runs a quarterly job. Acting on scanner output without context is how a hardening programme causes its first outage and loses the engineering goodwill it needs.

Tool / Platform	Practical Use in Baseline Work
`gcloud` CLI	Controlled inventory, policy inspection, and validation commands
Security Command Center	Centralised misconfiguration and exposure signal aggregation across your org
Cloud Asset Inventory	Asset ownership, IAM bindings, and configuration relationship mapping
Cloud Logging	Audit event review and control verification
Cloud Monitoring	Operational signal and alerting configuration
SIEM export pipeline	Cross-domain correlation and long-term incident analysis

Assessment sequence that works in practice:

Pull your asset and IAM inventory using Cloud Asset Inventory or gcloud
Compare current state against your baseline checklist controls
Score gaps by risk priority using the matrix above
Validate findings with actual service owners before assuming the finding is a problem
Plan phased remediation with rollback readiness for changes that could affect production

Step 4 matters more than it sounds. Context from service owners frequently changes the priority or the remediation approach — and skipping it is the difference between a programme engineers cooperate with and one they route around.

Security Command Center deserves a specific caveat: its Standard tier covers a limited set of detectors, and most of the findings people expect from it — including the deeper misconfiguration and threat detection — sit in the Premium or Enterprise tiers. If your baseline assumes SCC is watching something, verify which tier you are on before you write that assumption into a control document.

6) IAM baseline specifics — this is where drift causes the most long-term damage

IAM drift is the largest sustained risk in most GCP estates because it is incremental and quiet. Nobody ever grants Owner maliciously. Somebody is blocked on a Friday, the fastest unblock is a broad role, and the follow-up ticket to narrow it is never the most urgent thing in anyone’s week. Repeat for two years.

The asymmetry is what makes it stick: granting a role takes thirty seconds and carries no risk to the person doing it, while removing one requires proving nothing depends on it — and GCP will not tell you that. IAM Recommender helps, since it bases suggestions on 90 days of observed usage, but read its blind spot carefully: a role used only by a quarterly process looks unused for most of the year. Treat its output as a candidate list to check with owners, never as a list to action.

IAM hardening controls:

Stop using primitive roles (Owner, broad Editor bindings) as a convenience shortcut
Prefer group-based access over direct user bindings — it’s easier to manage and audit
Scope role assignments at the lowest practical resource level (project or resource, not organisation where avoidable)
Maintain clear separation between human admin identities and workload service accounts
Review service account key age and usage; rotate or remove stale keys
Enforce an approval process for any privileged role grants

IAM Check	What to Look For	Action
Primitive role overuse	Excess Owner or broad Editor bindings across projects	Replace with scoped predefined or custom roles
Direct user privilege grants	Individual high-privilege bindings to specific users	Migrate to managed groups with an approval workflow
Service account sprawl	Unclear ownership and ambiguous role purpose	Tag ownership and progressively reduce role scope
Key hygiene issues	Old or unused service account keys	Rotate and revoke; prefer Workload Identity Federation for keyless patterns

Workload Identity Federation lets external workloads authenticate with short-lived tokens instead of downloaded key files, and it is well supported across the major CI/CD systems. If your automation still ships around JSON key files, this is the single highest-value migration on the list — a service account key is a bearer credential with no expiry that will sit in a CI variable until somebody deliberately revokes it, and its usage looks identical whether it is your pipeline or someone who copied it.

The cost is real: WIF requires trust configuration on both sides, the failure messages when the subject or audience mapping is wrong are unhelpful, and it is genuinely harder to debug than “paste the key and it works”. Budget a day per CI system for the first one. You can also block the problem at source with the iam.disableServiceAccountKeyCreation organisation policy constraint — worth applying to new folders early, before anyone builds a dependency on key files that you then have to unpick.

7) Logging baseline — without reliable logs, incident response is guesswork

Logging is the only control on this list whose value is entirely retrospective, which is exactly why it loses budget arguments. It also has a property that makes it unforgiving: coverage is not retroactive. Enable Data Access logs today and you learn nothing about yesterday. The investigation you cannot run is the one where an attacker was present three weeks before anyone noticed.

Logging baseline controls:

Enable required Cloud Audit Logs at the appropriate scope — org, folder, or project — for Admin Activity and Data Access events
Route critical log events to durable, separate storage and/or a SIEM via log sinks
Define retention periods that align with your policy and regulatory requirements
Protect log integrity with access controls and separation of duties between teams that generate logs and those who could modify them
Monitor for logging pipeline failures and dropped events — a silent logging failure is worse than a noisy one

Signal	Interpretation	Follow-up
Sudden drop in auth or admin events	Ingestion or configuration drift	Validate sinks and logging policies immediately
Missing events for privileged operations	Coverage gap in audit configuration	Correct log type enablement and re-verify
High delay between event time and availability	Pipeline latency issue	Tune routing and processing path

One practical control is worth more than the rest of this section: alert on log volume, not just on log content. A broken sink, a revoked writer permission, or an exclusion filter somebody widened produces no error anywhere — it produces silence, and silence is indistinguishable from a quiet week. Every detection you have built sits downstream of ingestion, so a pipeline failure disables all of them at once while every dashboard stays green. Set a threshold on expected volume per critical project and page on the floor being breached.

The trade-off with sinks to separate storage is cost and duplication: you are paying to store the same events twice, once in Cloud Logging and once in your SIEM. Decide retention per destination rather than defaulting to the longest period everywhere.

8) Network and storage baseline — most cloud exposure comes from misconfiguration, not intrusion

The majority of public cloud exposure incidents involve no attack technique at all. A firewall rule opened for a debugging session in 2023. A bucket made public so a contractor could fetch one file. A default nobody changed. The adversary’s contribution was running a scanner, which is not a capability worth defending against so much as an ambient condition — anything reachable is found within hours.

Two GCP-specific defaults are worth knowing. The auto-created default VPC ships with permissive rules including SSH and RDP open to 0.0.0.0/0, so a project created casually starts life exposed; the compute.skipDefaultNetworkCreation constraint prevents that at the organisation level. And storage exposure is best solved by the storage.publicAccessPrevention constraint rather than by scanning for public buckets after the fact, since a policy constraint stops the mistake being possible while a scanner only tells you it already happened.

The trade-off on both is the same: an organisation policy that blocks a thing engineers currently do will surface as a confusing permission denial in someone’s Terraform run. Announce the constraint before you enforce it, and have the exception process ready on the day it goes live rather than a week later.

Network baseline essentials:

Default-deny ingress where practical — allow lists beat deny lists for security posture
Restrict management interfaces and administrative access to approved network paths
Segment workloads by environment and trust level using separate VPCs or subnets
Apply egress controls to sensitive workloads to prevent unexpected data exfiltration paths
Document every exception with a named owner and an expiry date — undocumented exceptions become permanent

Storage baseline essentials:

Private-by-default bucket policy enforced at the organisation level through Organization Policy constraints
All public access exceptions require explicit approval and documentation
Bucket and object access governed by least-privilege IAM, not legacy ACLs where avoidable
Monitoring configured for policy or ACL changes that could increase exposure
Access and retention controls aligned to data classification

Area	High-Risk Pattern	Baseline Expectation
VPC Firewall	Broad internet ingress rules to internal services	Explicit allow rules only for required sources and services
Admin Access Paths	Direct broad admin access from the public internet	Controlled access with strict identity verification and network controls
Cloud Storage	Public bucket access enabled by default or accidentally	Public access disabled at org policy level unless documented exception
Inter-project Connectivity	Untracked or undocumented trust paths between projects	Documented and periodically reviewed connectivity policies

9) Managing exceptions without letting them accumulate into hidden risk

Exceptions are not a failure of the baseline; a baseline with no exception process gets bypassed silently instead, which is strictly worse because you lose the visibility as well as the control. The problem is the untracked exception — the one nobody remembers approving, protecting a workload nobody can name, that everyone is now too nervous to remove.

Every exception record needs:

The specific control being bypassed
A clear business justification for why the deviation is necessary
A named risk acceptance owner who is accountable
Compensating controls that reduce the risk of the deviation
An expiration date and review schedule
Validation evidence showing the compensating controls are working

Exception Attribute	Required Value
Approval	Named accountable manager + security reviewer
Duration	Time-bounded with an explicit review date
Compensating Control	Documented technical or operational mitigation
Visibility	Included in monthly governance reporting
Closure Criteria	Defined condition that would allow the exception to be removed

No exception should be permanent without periodic executive-level review. If something has been “temporary” for two years, it needs a hard decision: fix it, accept it formally, or escalate.

10) Common GCP baseline mistakes to avoid

Every one of these turns up in assessments often enough to be predictable:

Project sprawl without naming conventions or ownership assignment
Owner-level access granted for convenience and never scoped down
Buckets accidentally made public through IAM changes or default setting changes
Missing log retention and no validation that log pipelines are actually working
Service account key files left active long after they’re needed
Firewall rules broadened during an incident or change window and never reverted afterward
Baseline documented once in a wiki and then never operationalised or revisited

The last one is the most common and the least discussed. A baseline that exists only as a document is not a control, it is a description of a control, and the gap between the two is where every assessment finding lives.

Anti-drift guardrails that actually help:

Monthly baseline conformance review with a fixed agenda and named participants
Change-control integration for IAM, network, and storage policy changes
Automated compliance checks in CI/CD pipelines where infrastructure is code
Quarterly exception review to close or formally re-accept accumulating exceptions

11) 30-day GCP hardening roadmap

Thirty days gets you meaningful coverage on the highest-risk projects, not a finished programme, and it is worth saying that out loud to whoever asked for the plan. The sequencing is deliberate: visibility first, because remediating what you cannot see is guesswork; identity and exposure second, because they carry the largest blast radius; logging third, because it is what makes month two survivable.

Week 1: Establish visibility and ownership

You can’t fix what you can’t see. Inventory all projects, identities, service accounts, and storage buckets. Tag owners for critical workloads and classify them by risk level. Identify your top public exposure and privilege risks so Week 2 is focused.

Output: baseline gap register v1

Week 2: Address critical identity and exposure gaps

Reduce the highest-risk IAM grants — prioritise Owner-level bindings and direct user assignments to sensitive resources. Lock down any public storage exposures immediately. Tighten the most dangerous firewall rules that are providing no legitimate business value.

Output: critical-risk remediation change set

Week 3: Logging, monitoring, and detection alignment

Validate that audit log coverage actually exists where you think it does. Check that log sinks are functioning and routing to the right destinations. Integrate high-value signals into SIEM workflows. Set up alerts for privileged changes and exposure drift.

Output: logging assurance and detection baseline report

Week 4: Governance hardening and sustainability

Implement an exception register with a defined review cadence. Finalise baseline policy documentation in a format engineering teams can actually use. Present status, residual risk, and next-quarter priorities to leadership.

Output: 30-day hardening completion report + roadmap

12) Metrics that indicate baseline maturity

Metric	Why It Matters	Target Direction
% projects with defined owner tags	Foundation of all governance — you can’t manage what nobody owns	Up
% privileged identities with MFA enforced	Identity assurance maturity for high-impact access	Up
Count of public-exposure exceptions with documentation	Exposure risk and governance discipline combined	Down (while documented count stays up)
% service accounts using Workload Identity Federation or recent key rotation	Credential hygiene quality	Up
Audit log coverage across critical projects	Incident readiness — can you investigate when something happens?	Up
Mean time to remediate critical baseline gaps	Program execution speed and team responsiveness	Down

One caution on metrics: every one of these can be gamed, and the pressure to game them arrives the moment they reach a leadership slide. Owner tags get filled with a team alias nobody reads. Exception counts fall because exceptions stopped being recorded. Read the metrics alongside the underlying register, and treat a suspiciously fast improvement as a question rather than a win.

A strong baseline is an operating rhythm, not a checkbox exercise: consistent control definitions, clear ownership, evidence-backed validation, and reviews frequent enough that cloud growth stays inside boundaries somebody chose.

Baseline operations worksheet for GCP teams

Workstream	Owner	First Action	Validation Signal
Project governance	Cloud platform lead	Enforce naming and owner standards for all new and existing projects	Fewer orphaned or ambiguous projects in monthly audit
IAM hygiene	Identity admin	Audit primitive role usage and stale service accounts with keys	Measurable reduction in broad-access assignments
Logging assurance	Security operations	Validate audit log coverage and verify log sink integrity	Reliable event visibility for critical administrative actions
Exposure control	Cloud security engineer	Review public endpoints and bucket exposures on a weekly cadence	Faster closure of accidental exposure findings

Governance checklist — run this monthly

Confirm owner mapping for all new projects and critical resources added since last review
Validate exception register: check for expired approvals and items past their review date
Review recent firewall and storage changes for unintended drift
Track all unresolved high-priority baseline gaps with assigned owners and due dates

Control validation and handoff pack

When handing off GCP security governance or presenting to leadership or auditors, these artefacts cover what they’ll ask for:

Artifact	Minimum Content	Consumer
Baseline gap register	Control gap, risk level, assigned owner, due date	Security + platform leads
Validation evidence	Commands, screenshots, or log references per control	Audit and governance teams
Exception record	Justification, compensating controls, expiry date	Risk owners
Quarterly status brief	Progress trends, metric movement, and unresolved risk clusters	Leadership stakeholders

Quality checks before any handoff:

Are all critical baseline gaps assigned with realistic deadlines and accountable owners?
Can each claimed control be validated with actual evidence rather than assumption?
Is the exception list shrinking over time, or accumulating without closure?

90-day baseline execution cadence

Days 1–30

Reconcile your project inventory and confirm owner mapping. Prioritise and close the top critical exposure and IAM gaps identified in Week 1 of the 30-day roadmap. Validate that required logging controls are active across your highest-value projects.

Days 31–60

Harden firewall and storage controls in remaining high-risk projects that weren’t addressed in the first month. Improve service account governance — reduce key usage in favour of Workload Identity Federation where possible. Build recurring compliance checks into your infrastructure change workflows.

Days 61–90

Run your first quarterly baseline conformance review. Measure actual risk reduction against your opening baseline gap register. Publish your next-cycle hardening roadmap with specific, measurable targets.

KPI	Why It Matters
Projects with complete owner metadata	Governance completeness — foundational to all other controls
Critical baseline gaps closed	Core hardening progress metric
Exception count with valid and current expiry dates	Exception control maturity
Audit log coverage on critical projects	Incident readiness quality

Baseline maturity grows when teams combine technical controls, governance ownership, and recurring validation into a stable operating model rather than treating each as a separate one-time effort.

Baseline verification and drift management

A baseline is only meaningful if you keep verifying it holds. The fastest way to lose posture is to treat baseline work as a project with a completion date — the controls do not decay, but the environment around them changes until they no longer cover it.

Drift signals to monitor actively:

Area	Drift Signal	Why It Matters
IAM	New high-privilege bindings or broad primitive role assignments	Expands blast radius quickly and quietly
Logging	Disabled sinks, audit logs turned off, reduced retention settings	Removes your investigation capability exactly when you need it
Network	New public IP addresses or expanded firewall allow rules	Increases attack surface incrementally
Storage	Buckets becoming public or IAM policies weakened	Creates data leakage risk that may not be immediately visible

Baseline evidence pack for audits and reviews:

IAM review summary covering principals, privileged roles, and documented exceptions
Logging configuration snapshot with audit log settings, active sinks, and retention policies
Network exposure summary covering public services and firewall rule highlights
Storage posture summary covering public access control settings and encryption defaults

Change management standards that prevent drift:

Any change introducing public exposure or elevated privileges requires explicit named-owner approval before implementation
Exceptions are time-boxed with a hard expiry date and a linked follow-up ticket
Baseline controls are reviewed on a fixed cadence — monthly for critical projects, quarterly for everything else

KPI	Target Direction
Privileged principals without documented justification	Down to zero
Logging coverage for critical projects	Up to 100%
Publicly exposed services without a documented owner	Down to zero
Baseline exceptions past their expiry date	Down to zero

That is what a working GCP baseline looks like: controls you can verify rather than assert, posture you can measure, and drift and exceptions handled strictly enough that the baseline still means something two years and four hundred projects from now.