Screenata

Integrations / Cloud & infrastructure

Screenata + Google Cloud

How 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.

Each area below is scanned on a schedule. A finding is not a green checkmark: it is a signed artifact an auditor can verify, mapped to the exact requirement it satisfies.
Evidence area
What the checks verify
Maps to
Identity & access (IAM)

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.

SOC 2CC6.1HIPAA§164.312(d)ISO 27001A.5.15
Storage encryption

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.

SOC 2CC6.1HIPAA§164.312(a)(2)(iv)ISO 27001A.8.24
Audit logging

Audit log coverage across projects and whether administrative activity is captured and retained.

Proof that administrative activity is recorded, which monitoring controls depend on.

SOC 2CC7.2HIPAA§164.312(b)ISO 27001A.8.15
Firewall rules

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.

SOC 2CC6.6ISO 27001A.8.20

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.

Each row is a real native check, the framework control it produces evidence for, and the risk it closes. This is what continuous Google Cloud compliance actually looks like. Checks run on a schedule; a failing check opens a ticket and re-verifies after a human applies the fix.
Check & why it matters
Maps to

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.

SOC 2A1.1SOC 2CC7.2ISO 27001A.8.16

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.

SOC 2CC1.3SOC 2CC6.3ISO 27001A.5.15HIPAA§164.308(a)(1)(ii)(b)

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.

SOC 2CC1.3ISO 27001A.5.15HIPAA§164.308(a)(3)(i)

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.

SOC 2CC6.2ISO 27001A.8.1HIPAA§164.308(a)(1)(ii)(b)

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.

SOC 2CC6.7ISO 27001A.8.12HIPAA§164.312(e)(1)

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.

SOC 2CC7.4SOC 2CC7.5ISO 27001A.8.13HIPAA§164.308(a)(1)(ii)(b)

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.

SOC 2CC6.6SOC 2CC6.7HIPAA§164.308(a)(1)(ii)(b)

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.

SOC 2CC6.6ISO 27001A.8.1HIPAA§164.308(a)(1)(ii)(b)

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.

SOC 2CC6.1ISO 27001A.8.1HIPAA§164.308(a)(1)(ii)(b)

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.

SOC 2PI1.5ISO 27001A.5.16HIPAA§164.308(a)(1)(ii)(b)

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.

SOC 2A1.1SOC 2CC2.1ISO 27001A.8.15HIPAA§164.308(a)(1)(ii)(d)

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.

SOC 2C1.1SOC 2CC6.7ISO 27001A.8.11

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.

SOC 2A1.1SOC 2C1.2ISO 27001A.8.10

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.

SOC 2CC6.1SOC 2PI1.4

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.

SOC 2C1.1SOC 2CC6.7

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.

SOC 2C1.1SOC 2CC6.7ISO 27001A.8.11

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.

SOC 2A1.1SOC 2CC7.2ISO 27001A.8.16

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.

SOC 2CC6.6SOC 2CC6.7

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.

SOC 2CC3.1SOC 2CC3.2

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.

SOC 2CC6.1ISO 27001A.5.9HIPAA§164.308(a)(4)

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.

SOC 2CC6.6SOC 2CC7.2ISO 27001A.8.15HIPAA§164.308(a)(1)(ii)(D)

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.

ISO 27001A.8.24HIPAA§164.312(c)(1)

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.

You create a service account with read-only access to your projects and Screenata uses it for scheduled scans. Vera never receives write access to your infrastructure, and credentials never touch the Screenata database. Weekly cloud scans run automatically; findings are hashed and stored as evidence the moment they land.

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.

Google Cloud FAQ

What teams ask before connecting.

Full provider list on the integrations page.
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.

Pricing

Related: AWS · Azure · Kubernetes · Google Workspace