Google Cloud compliance monitoring:
20 read-only checks, 8 read-only roles.

The Google Cloud integration runs 20 read-only checks against one project: Cloud SQL encryption in transit, public exposure, backups, point-in-time recovery, deletion protection and high availability; IAM, covering service accounts with Owner or Editor, the number of owners, personal accounts and user-managed keys; Data Access audit logs and log retention; Cloud Run public ingress, runtime service accounts and warm API instances; container scanning; uptime checks and alerts; secret rotation; and Security Command Center.

The checks began as the ones we ran by hand against our own project during a SOC 2 readiness review, turned into something that runs on connect. They call Google's REST APIs directly, with no client library, and each one reads configuration and decides. A call Google refuses is reported with Google's reason, never as a pass.

A check over several resources passes only if every resource passes. One that could not be read makes the whole check could not verify, not a pass on the rest.

Each check returns one of four results: pass, fail, not applicable (nothing of that kind exists, or a plan limit makes the setting unavailable) or could not verify (the call was refused or failed). A check over several resources shows a value such as 6/8 passing and names every resource it looked at. Nothing is simulated, and a check that could not look is never shown as a pass.

Only passing checks become evidence: one evidence item for each reference in the last column, so a single pass can evidence SOC 2, ISO/IEC 27001 and the DPDP Act at once. Each item expires after 90 days and every sync renews it, so evidence from a connection that has stopped syncing stops counting. A failing result is shown on the connected account with the resources that caused it, and is not filed as evidence.

Each check belongs to a shared control in the TryTrustable control library, and is filed only under requirements the library maps to that control. The same control answers the requirements below in other frameworks; the references are read from the library. The cross-framework mapping page explains how one result reaches several frameworks.

Requirement references are read from the TryTrustable control library. A dash means the library maps no requirement in that framework to this control.

The high-availability and warm-API-instance checks are marked informational: they are often cost or architecture decisions, so a fail is shown as a gap to decide on rather than an audit exception.

8 predefined read roles on the project: roles/iam.securityReviewer, roles/cloudsql.viewer, roles/logging.viewer, roles/run.viewer, roles/monitoring.viewer, roles/secretmanager.viewer, roles/serviceusage.serviceUsageViewer, roles/securitycentermanagement.viewer. roles/viewer is deliberately not needed: it reads nearly every resource in the project, including Cloud Storage object listings and BigQuery table metadata, which these checks do not use.

From the connector source. roles/cloudasset.viewer is not requested: no check calls the Cloud Asset API, and a role granted for a call that is never made is standing access with no purpose.

1. In the project, create a service account for TryTrustable, for example trytrustable-auditor
2. Grant it the 8 roles above on the project
3. Create a JSON key for it
4. In TryTrustable, open Integrations, choose Google Cloud and paste the key. The project checked is the one named in the key
5. The first sync runs immediately. Passing checks land in the evidence ledger; the platform re-syncs every six hours by default

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=serviceAccount:AUDITOR_EMAIL --role=roles/iam.securityReviewer
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=serviceAccount:AUDITOR_EMAIL --role=roles/cloudsql.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=serviceAccount:AUDITOR_EMAIL --role=roles/logging.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=serviceAccount:AUDITOR_EMAIL --role=roles/run.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=serviceAccount:AUDITOR_EMAIL --role=roles/monitoring.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=serviceAccount:AUDITOR_EMAIL --role=roles/secretmanager.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=serviceAccount:AUDITOR_EMAIL --role=roles/serviceusage.serviceUsageViewer
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=serviceAccount:AUDITOR_EMAIL --role=roles/securitycentermanagement.viewer

The key is encrypted at rest with AES-256-GCM and is never written to logs. If Google rejects it, the connection reports itself unverified and produces no checks. Cloud Run services that are meant to be public can be declared with the label trytrustable-public=true, so the decision is recorded rather than reported as a finding.