Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
Which GCP artifacts count as security evidence?
Last verifiedCloud Audit Logs evidence who did what, IAM policy and Policy Analyzer evidence authorisation, Security Command Center aggregates posture and produces compliance reports, and Cloud KMS evidences key control. Google's certifications cover the platform, not your projects.
Google Cloud evidence map, last verified 10 September 2026 against Google Cloud documentation for Cloud Audit Logs, Cloud Logging retention and log buckets, IAM, Policy Analyzer and Policy Troubleshooter, organisation policy constraints, Security Command Center and its compliance reports, Cloud KMS, VPC Service Controls, Assured Workloads, and Backup and DR Service, read alongside the CIS Google Cloud Platform Foundation Benchmark, the AICPA Trust Services Criteria, and ISO/IEC 27001:2022 Annex A. Google Cloud renames and repackages capabilities between releases, and Security Command Center capabilities are tier-dependent; Google Cloud documentation is the authority. Nothing here determines that a framework applies to your organisation. This page is not legal advice, does not determine YOUR obligations, does not start a clock, and does not file with an auditor.
What this page is, and what it is not
Audience: a platform engineer, security engineer, or compliance owner running workloads on Google Cloud who needs to know which artifact answers which audit question, and where Google's responsibility ends and yours begins.
This page is not legal advice. It does not determine YOUR obligations, does not decide which frameworks apply to your organisation, does not start a clock, and does not file anything with an auditor. A service listed next to a control is a mapping, not a conclusion that the control operated effectively. Last verified 10 September 2026.
The shared-responsibility split is the framing that matters most. Google is responsible for the physical infrastructure, the hardware and host layer, and the managed-service platform, and publishes its own audit reports and certificates through its compliance resource centre. You are responsible for identities and IAM bindings, network and perimeter configuration, encryption and key choices, log routing and retention, and your data.
- Cloud Audit Logs come in kinds with different default behaviour: admin activity logs are written without configuration and retained for a long default period, while data access logs are largely off by default and must be enabled per service. An absent data access log is usually a configuration decision, not a platform limitation.
- Retention is set per log bucket. The default bucket has a default retention; a custom bucket lets you set your own, and locking a bucket makes retention immutable. Record which you use for evidence.
- Organisation, folder, and project scope matter. An export at project scope is an incomplete population for an organisation-scoped control.
- Security Command Center capabilities and compliance reports depend on the service tier. Verify what your tier includes before promising an artifact.
Control-to-GCP-service map
Read the first column as the control assertion, the second as the Google Cloud artifact, the third as where to find it, and the fourth as the framework note. Last verified 10 September 2026 against Google Cloud documentation. Not legal advice.
| Control assertion | Google Cloud artifact | Where it lives (console path or API) | Framework note |
|---|---|---|---|
| Administrative actions are recorded and attributable | Cloud Audit Logs admin activity entries, queried for the period, plus the aggregated organisation-level log sink | Console → Logging → Logs Explorer, filtered to logName with cloudaudit.googleapis.com activity; sinks at Logging → Log router. | AICPA TSC CC7.2; ISO/IEC 27001:2022 Annex A 8.15; NIST SP 800-53 Rev. 5 AU family. PCI DSS v4.0.1 Requirement 10 where in scope. |
| Access to data is recorded where the risk warrants it | Data access audit log configuration per service, and the resulting log entries for the period | Console → IAM & Admin → Audit Logs, selecting services and log types; entries in Logs Explorer. | AICPA TSC CC7.2; Annex A 8.15. Data access logs are largely off by default — the configuration record is part of the evidence. |
| Log records are retained for the required period and protected | Log bucket retention settings, bucket lock where used, and the log sink to an archive destination such as Cloud Storage with retention policy and bucket lock | Console → Logging → Logs storage → the bucket → Retention; storage archive under Cloud Storage → the bucket → Protection. | AICPA TSC CC7.2; Annex A 8.15; PCI DSS v4.0.1 Requirement 10.5 where in scope, which asks for 12 months with three months immediately available. |
| Only authorised principals hold permissions, at least privilege | IAM allow policy per resource, custom role definitions, Policy Analyzer query results for who can do what, and recommender findings for excess permissions | Console → IAM & Admin → IAM for bindings; IAM & Admin → Policy Analyzer for queries; role recommendations surface on the IAM page. | AICPA TSC CC6.1–CC6.3; Annex A 5.15, 5.18 and 8.2; NIST SP 800-53 Rev. 5 AC family; PCI DSS v4.0.1 Requirements 7 and 8 where in scope. |
| Guardrails prevent dangerous configuration regardless of project owner | Organisation policy constraints and their effective evaluation per resource, plus the audit-log record of policy changes | Console → IAM & Admin → Organization policies; effective policy shown per resource node. | AICPA TSC CC7.1 and CC8.1; Annex A 8.9 configuration management. |
| Strong authentication is enforced for human access | Google Workspace or Cloud Identity two-step verification enforcement, security-key enforcement where used, and context-aware access policies | Admin console → Security → Authentication for the identity domain; BeyondCorp and access-level configuration in the Cloud console → Security → Access Context Manager. | AICPA TSC CC6.1; Annex A 5.17; PCI DSS v4.0.1 Requirement 8 where in scope. Identity is administered outside the Cloud console for Workspace-managed users. |
| Service identities are not over-privileged and keys are not long-lived | Service-account inventory, key listing showing user-managed keys and their age, organisation policy disabling service-account key creation, and Workload Identity Federation configuration | Console → IAM & Admin → Service accounts → Keys; the disableServiceAccountKeyCreation constraint under Organization policies. | AICPA TSC CC6.1; Annex A 5.16 and 5.17; NIST SP 800-53 Rev. 5 IA family. |
| Access reviews happen and are recorded | Periodic export of IAM bindings per scope, Policy Analyzer output for privileged permissions, and role recommendations, each with a named reviewer and date | Exports from the IAM and Policy Analyzer paths above, stored with reviewer and date in your evidence repository. | AICPA TSC CC6.2–CC6.3; Annex A 5.18. Cadence is your choice unless a contract sets it. |
| Posture is monitored and misconfiguration is detected | Security Command Center findings with state and mute status, Security Health Analytics detector coverage, and the service tier in effect | Console → Security → Security Command Center → Findings and Posture; tier under Security Command Center → Settings. | AICPA TSC CC7.1–CC7.2; Annex A 8.16. Detector coverage and some features are tier-dependent. |
| Configuration is measured against a named framework baseline | Security Command Center compliance reports for the selected standard, and the per-control detail behind the report | Console → Security → Security Command Center → Compliance, then the standard. | Google publishes reports aligned to CIS Google Cloud Platform Foundation Benchmark, PCI DSS, ISO/IEC 27001 and other references. The alignment is Google's mapping — not certification, not an attestation, and not an auditor's conclusion. Availability is tier-dependent. |
| Data at rest is encrypted with keys you control where required | Cloud KMS key inventory, key rotation schedules, IAM bindings on keys, customer-managed encryption key configuration per resource, and KMS audit logs of key use | Console → Security → Key Management → the keyring and key → Rotation and Permissions; per-resource CMEK settings on the resource. | AICPA TSC CC6.7; Annex A 8.24 use of cryptography; PCI DSS v4.0.1 Requirements 3 and 4 where in scope. |
| A perimeter limits where data can move | VPC Service Controls perimeter definitions, dry-run and enforced status, and violation entries in audit logs; Assured Workloads folder configuration where a regulated regime applies | Console → Security → VPC Service Controls; Assured Workloads under Compliance → Assured Workloads. | AICPA TSC C1.1 and CC6.6; Annex A 8.22 segregation of networks. Assured Workloads supports specific regimes; it does not itself make you compliant with them. |
| Backups exist and restoration has been demonstrated | Backup and DR Service plan and job history, or per-service backup configuration, plus a recorded restore test with date and outcome | Console → Backup and DR; per-service backups under the relevant product, for example Cloud SQL → Backups. | AICPA TSC A1.2–A1.3; Annex A 8.13 and 5.29–5.30. The restore record is the evidence; a plan alone is not. |
Legal requirement, guidance, best practice, or our recommendation
A benchmark score is not a legal position, and a compliance report from a cloud console is not an attestation. Label the reason each control exists. Last verified 10 September 2026. Not legal advice.
| Statement | Which kind of authority | What it does not mean |
|---|---|---|
| PCI DSS v4.0.1 Requirements 3, 4, 7, 8 and 10 on encryption, access, and logging. | Legal requirement in the contractual sense, for entities in scope through card-brand and acquirer agreements. | Does not apply where no cardholder data is in scope, and does not name any Google Cloud service. |
| NIST SP 800-53 Rev. 5 AC, AU, CM, and SI families. | Regulatory and standards guidance, binding on US federal systems through separate authority such as FedRAMP. | Does not bind a commercial company that has not contracted to it. |
| CIS Google Cloud Platform Foundation Benchmark recommendations. | Industry best practice — a community consensus benchmark from the Center for Internet Security. | Not a law and not a certification. Recorded deviations are defensible; unrecorded ones are the finding. |
| AICPA Trust Services Criteria and ISO/IEC 27001:2022 Annex A. | Attestation criteria and certification requirements, applying because you sought a report or certification, or a contract requires one. | Neither names a Google Cloud service. The mapping above is yours to own. |
| Aggregate audit logs to an organisation-level sink in a project the workload teams cannot write to, and enable data access logs for the services holding sensitive data. | Industry best practice, and widely expected of an organisation-scoped estate. | Not written as a requirement in any framework named here, and the volume cost of data access logs is a real design constraint to record. |
| Export IAM bindings, Policy Analyzer results for privileged permissions, and service-account key age on a fixed cadence, each with a named reviewer and date. | ShipReady Metrics recommendation. | Does not make the control effective by itself, and is not required by any framework named here. |
Checklist
A question list for the Google Cloud side of your evidence set. Not a determination that any framework applies to you. Last verified 10 September 2026. Not legal advice.
- Do we have the complete organisation, folder, and project scope list for the audit, and is our evidence exported at the right scope?
- Is there an organisation-level log sink to a destination the workload teams cannot modify?
- Are data access logs enabled for the services that hold sensitive data, and is the decision for those that are off recorded with a reason?
- Does log-bucket retention meet the period we claim, and is any archive bucket locked?
- Can we produce the IAM bindings for every in-scope project as they were during the period, not only today?
- Are there user-managed service-account keys, and is key creation restricted by organisation policy?
- Do any human principals hold owner or editor at project scope, and is that justified in writing?
- Which Security Command Center tier do we hold, and which detectors and compliance reports does it actually include?
- Are Security Command Center findings dispositioned with an owner and a decision, including muted findings?
- Has a restore actually been performed and recorded in the period?
What to do now
Ordered so the most-requested artifacts become producible first. None of these steps is a legal determination, and none files anything with an auditor.
- Fix the scope list at organisation, folder, and project level, and export evidence at the highest scope that covers the audit population.
- Create an organisation-level aggregated log sink into a dedicated logging project, with a locked archive bucket where your retention requires immutability.
- Decide data access logging service by service, and record both the enablements and the deliberate exclusions with their reasons — including volume cost, which is a legitimate reason when written down.
- Restrict service-account key creation by organisation policy and move workloads to Workload Identity Federation, then keep the key inventory as evidence that long-lived keys are absent.
- Schedule IAM binding and Policy Analyzer exports with a named reviewer and date. That is your access-review artifact.
- Confirm your Security Command Center tier, then enable one compliance report and work its failures with owners. Record that the report is an internal indicator, not certification.
- Perform and record one restore test in the period.
- Re-verify Google Cloud documentation for service behaviour, tiering, and console paths annually, and record the date. Ours says 10 September 2026.
Where this shows up in ShipReady Metrics
Only shipped behaviour is described here. This product does not configure your Google Cloud organisation or projects, does not enable audit logs, does not produce an auditor's opinion, and does not file anything with an auditor.
If you already have a session: signed-in app → Compliance holds evidence collection, which records control-mapped artifacts for starter control subsets, and evidence review, where a named human accepting a manual row renders it met and rejecting it renders it a gap, with a timestamp. Cloud configuration artifacts are typically manual rows reviewed that way. That overlay is a timestamped compliance artifact — not a forensic chain of custody, not a downloadable evidence binder, and not an auditor's opinion.
The obligation map lists frameworks your organisation marked in-scope. That mark is a scoping input you control, not a legal opinion that a framework applies. Readiness is an internal indicator, not certification.
Vulnerability management in this product covers application and dependency findings from connected sources, ranked with CISA KEV membership, EPSS, and CVSS, with cross-source deduplication and blast-radius search over captured dependencies. It is not a Google Cloud configuration assessor.
Primary sources (last verified 10 September 2026)
Google Cloud documentation is the authority for every service behaviour and console path above; framework references are labelled by the kind of authority they carry.
Google Cloud documentation for Cloud Audit Logs, Cloud Logging retention and log buckets, the log router, IAM and custom roles, Policy Analyzer, organisation policy constraints, Security Command Center including Security Health Analytics and compliance reports, Cloud KMS, VPC Service Controls, Assured Workloads, and Backup and DR Service, together with Google's shared-responsibility and shared-fate guidance and its compliance resource centre for Google's own certifications. The CIS Google Cloud Platform Foundation Benchmark is community best practice. AICPA Trust Services Criteria are attestation criteria. ISO/IEC 27001:2022 Annex A is a certification requirement set. NIST SP 800-53 Rev. 5 is guidance for commercial organisations. PCI DSS v4.0.1 binds entities in scope through contract. Not a complete list, and not legal advice.
The AWS and Azure pages in this cluster are the equivalent maps. The IAM page covers the access lifecycle, and the log-retention page covers how long to keep what these services produce.