Integrations / Cloud & infrastructure
Screenata + Google CloudHow do you continuously monitor Google Cloud for SOC 2, ISO 27001, and HIPAA?
Quick answer
Yes, you can run a SOC 2, ISO 27001, or HIPAA compliant workload on Google Cloud, but Google Cloud itself is not the thing that gets audited. Google certifies its own infrastructure layer and publishes its own attestation reports for it. Your project configuration, IAM posture, encryption settings, and audit logging are yours to get right and yours to evidence. Screenata runs 55 native checks against that configuration on a schedule and turns each result into signed evidence mapped to the control it satisfies.
Screenata connects to Google Cloud through a read-only service account and runs 55 native checks against your project configuration: IAM posture, storage encryption, audit logging, and firewall rules. Each finding becomes a signed, timestamped evidence artifact mapped to SOC 2, HIPAA, and ISO 27001 controls through a shared control catalog, so one scan feeds every framework you run.
55 native checks · read-only · signed evidence
What it proves
Google Cloud evidence, mapped to controls.
IAM posture across projects, including how access is granted and whether it follows least privilege.
Proof that production access is controlled and scoped, the first thing an auditor samples.
Encryption at rest on storage buckets and whether any bucket is exposed more broadly than intended.
Per-bucket findings showing encryption at rest, mapped to the encryption requirements in each framework.
Audit log coverage across projects and whether administrative activity is captured and retained.
Proof that administrative activity is recorded, which monitoring controls depend on.
Open ingress on sensitive ports, wide source ranges, and rules that expose more than the network design intends.
Findings that production networks restrict inbound access to what the system description claims.
Control references are the requirements each evidence area supports, via the shared control catalog. Your auditor decides sufficiency; the artifacts are theirs to verify.
Compliance checks
What Screenata checks on Google Cloud, and why each matters.
IAM Audit Logs Enabled
Without audit logging there is little visibility into who accessed data or changed configuration, which hinders detection and forensics. An auditor verifies Cloud Audit Logs capture admin and data-access events.
Service Accounts Have No Admin Privileges
Over-privileged service accounts let a single compromise read, alter, or delete broad resources. An auditor checks that service accounts do not hold Owner, Editor, or admin roles at the project level.
No User-Managed Service Account Keys
User-managed keys are downloadable and long-lived, so a leaked key lets an attacker impersonate the service account. An auditor verifies service accounts have no user-managed keys.
Cloud SQL No Public Access
Authorizing 0.0.0.0/0 makes the database reachable from the internet for brute force and unauthorized queries. An auditor confirms Cloud SQL instances are not publicly accessible.
Cloud SQL SSL Required
Without enforced TLS, database traffic can be intercepted or altered on untrusted networks. An auditor verifies Cloud SQL requires SSL connections.
Cloud SQL Automated Backups
Without automated backups, deletes, corruption, or ransomware can become irreversible with no point-in-time recovery. An auditor checks that automated backups are enabled.
Firewall SSH/RDP from Internet
A firewall rule opening SSH or RDP to 0.0.0.0/0 exposes admin ports to internet-wide brute force. An auditor verifies these ports are not open to the internet.
Compute Instances Without Public IP
An external IP puts a VM directly on the internet where it can be scanned and attacked. An auditor confirms compute instances do not carry public IP addresses.
Storage Bucket Public Access
A public bucket lets anyone list or download objects, and write access allows tampering. An auditor verifies buckets do not grant access to allUsers or allAuthenticatedUsers.
KMS Key Rotation Enabled
Without rotation, a compromised key can decrypt data and backups for longer and widen the blast radius. An auditor checks that KMS crypto keys have rotation configured.
Log Sinks Created
Without a log sink, audit evidence can expire or be altered in-project, which hinders detection and forensics. An auditor verifies at least one sink exports logs to durable storage.
BigQuery datasets use customer-managed encryption keys
With Google-managed keys you lose control of key rotation and revocation for data at rest. An auditor confirms BigQuery datasets use customer-managed encryption keys.
Cloud Storage bucket retention policy is locked
Without a locked retention policy, exported logs can be deleted early or shortened to hide activity. An auditor verifies log buckets have a retention period with Bucket Lock applied.
Cloud Storage uniform bucket-level access enabled
Without uniform access, object ACLs can bypass bucket IAM and grant unintended public reads. An auditor checks that uniform bucket-level access is enabled.
Compute instances have confidential computing enabled
Without confidential computing, data in memory can be exposed through host or hypervisor compromise. An auditor verifies Confidential VM is enabled on instances.
Compute instance disks use Customer-Supplied Encryption Keys
With provider-managed keys you cannot control the key lifecycle or revoke access quickly. An auditor confirms instance disks use customer-supplied encryption keys.
Subnetworks have VPC Flow Logs enabled
Without flow logs, network activity lacks visibility, which enables covert exfiltration and undetected lateral movement. An auditor verifies flow logs are enabled at the subnet scope.
DNS managed zones have DNSSEC enabled
Without DNSSEC, DNS responses can be spoofed to redirect users to attacker hosts. An auditor checks that managed zones have DNSSEC enabled.
Container vulnerability scanning enabled
Without image scanning, vulnerable packages can reach production and enable remote code execution or supply chain compromise. An auditor verifies container vulnerability scanning is enabled.
Cloud SQL Deletion Protection
Without deletion protection, a single mistake or errant script can permanently destroy a production database and its recovery window. An auditor confirms deletion protection is enabled on each instance.
Security Command Center enabled
Without a central detection surface, misconfigurations and active threats across projects can persist undetected. An auditor verifies Security Command Center is enabled for the organization.
Cloud Storage Bucket Object Versioning Enabled
Without versioning or retention, a single overwrite or delete permanently destroys the prior object with no recovery path. An auditor checks that buckets enable object versioning or a retention policy.
Drawn from Screenata’s Google Cloud check library. Control refs are the requirements each check produces evidence for; your auditor decides sufficiency.
How it connects
Read-only, revocable, yours.
Read-only by construction
OAuth scopes and IAM roles are scoped to read. Vera never gets write access to your systems.
Signed findings
SHA-256 per artifact, RSA/ECDSA signatures, RFC 3161 timestamps. Verifiable without a Screenata account.
Mapped to controls
Each finding lands on the shared control catalog, so one scan satisfies SOC 2, HIPAA, and ISO 27001 at once.
BAA & attestation status
Google Cloud offers a Business Associate Agreement covering the products it lists as HIPAA-included in its documentation, and it publishes SOC and ISO reports for its own infrastructure. That published list is the boundary: PHI is expected to stay inside it. The agreement does not settle your side. IAM posture, encryption keys, audit log coverage, and firewall rules remain your configuration and your evidence.
What access does Screenata need to my Google Cloud projects?
A read-only service account that you create and control. Screenata uses it for scheduled scans and never receives write access. You can inspect exactly what the account permits before connecting, and revoke it at any time from your own Google Cloud console.
Is the Google Cloud integration enough for SOC 2?
It covers the infrastructure slice: access control, encryption, logging, and network boundary evidence from your projects. A full SOC 2 program also needs policies, HR and vendor evidence, and organizational controls, which come from your other connections and documents. About 70% of evidence across a typical program is collected automatically.
How often do the Google Cloud checks run?
On a schedule, with weekly cloud scans as the default cadence. Each run produces fresh findings, and evidence freshness is tracked so anything approaching staleness gets flagged before an auditor sees it.
Can my auditor verify the Google Cloud evidence independently?
Yes. Every finding is hashed with SHA-256, signed with RSA or ECDSA, and timestamped under RFC 3161. The evidence pack verifies with a free CLI outside Screenata, so the auditor does not have to trust a dashboard screenshot.
What are the steps to implement SOC 2 with Google Cloud?
First, connect your projects with a read-only service account so the scan can see your configuration without any write path. Second, let the first scan run and establish a baseline of where the projects stand against the SOC 2 control set, instead of guessing which controls are already met. Third, fix what fails, which in most projects means removing bucket grants to allUsers and allAuthenticatedUsers, deleting user-managed service account keys, closing firewall rules that open SSH or RDP to the internet, requiring SSL on Cloud SQL and taking it off public access, and turning on Cloud Audit Logs with a sink to durable storage. Fourth, let the scheduled scans collect the passing results as signed, timestamped evidence, so you build a history over the observation window rather than a single snapshot. Fifth, hand the evidence package to an independent auditor. The audit itself is a separate engagement you contract with a CPA firm; Screenata produces the evidence, it does not issue the report.
Is Google Cloud HIPAA compliant?
No cloud provider is HIPAA compliant on its own, and Google does not claim Google Cloud is. Google will sign a BAA covering the products it lists as HIPAA-included, which makes those products usable for PHI. Compliance is a property of how you configure and operate your workload on top of them. What makes the difference is encryption at rest and in transit, IAM that follows least privilege, audit logging that captures admin and data-access events and is exported somewhere durable, and evidence that those controls actually operated over time rather than on the one day you looked.
Do auditors accept evidence Screenata collects from Google Cloud?
Yes. Every finding is exported as a signed, timestamped artifact, a SHA-256 hash with an RSA or ECDSA signature and an RFC 3161 timestamp, that an auditor verifies outside Screenata with a free CLI. A person reviews and approves the evidence before it reaches the auditor. Screenata collects and signs it; it does not decide the audit result.
Connect and see
Fifteen minutes after connecting Google Cloud, you know your real posture.
Related: AWS · Azure · Kubernetes · Google Workspace