Google Cloud security assessment

Why teams commission a Google Cloud security assessment

A Google Cloud security assessment is an independent review of your projects and organization against the CIS Google Cloud Platform Foundation Benchmark at version 5.0.0, with targeted testing where configuration review alone does not answer the question. It covers IAM bindings, service account and key handling, network and firewall rules, storage exposure and audit logging. Teams usually commission one when a compliance framework asks for evidence of cloud configuration, when a customer security questionnaire asks how a GCP estate is governed, when a product is about to launch on Google Cloud, or when an insurer or auditor wants to see a documented baseline. In each case the question is the same: can you show, with specific settings and a named owner for each, that the environment matches a recognized standard?

The split of responsibility explains why this work matters. Google secures the underlying platform, including the physical infrastructure and the services it operates. The customer remains responsible for how those services are configured and used: who holds which roles, whether service account keys exist and how old they are, which firewall rules admit traffic from the internet, whether buckets are readable by allUsers, and whether Cloud Audit Logs are enabled and retained. Most cloud incidents trace back to these customer-side decisions rather than to platform failures, so the assessment concentrates there. Before you scope the work, confirm which projects, folders and organization-level policies sit in the boundary, and which parts of the estate a third party runs on your behalf. The practical value is a prioritized list of findings you can act on before an auditor or customer asks. A review of this kind typically surfaces over-broad primitive roles granted at the organization or folder level, long-lived service account keys that no longer have an owner, firewall rules open to wide source ranges, and log sinks that do not cover every project. Ask your provider to map each finding to the relevant CIS recommendation and to state whether the evidence came from configuration export, live testing or both. That mapping is what lets your compliance lead reuse the output in a control narrative without rewriting it.

What can be in scope for a Google Cloud security assessment

Scope decides what the assessment can prove and what it leaves unexamined. The decisions below connect the Google Cloud resource hierarchy, the people who administer it and the workloads that run on it, so each one should be agreed in writing before testing starts.

Organization and folder hierarchy

Decide whether the assessment covers a single project, a folder or the whole organization. Organization-level policies, folder inheritance and shared resources often set controls for many projects at once, so reviewing a single project can miss a weak inherited setting. Ask which organization policies apply, who owns them and whether the assessor will receive read access at the organization level for the configuration review.

The set of projects

List every project in scope by project ID, not by display name, and state which are production, shared services or sandbox. Projects created after the scope is signed can drift outside the agreed boundary, so confirm how new projects are added. Any project that holds data or workloads owned by a third party needs explicit confirmation before it is tested.

Identity and admin roles

Agree which identities the assessor will use for the configuration review, such as a read-only auditor role, and whether any testing identity will be given temporary elevated access. Cover Cloud Identity or Workspace super administrators, billing administrators and service accounts with broad roles. Record who can approve changes to IAM bindings during the engagement.

Production versus non-production

Decide which environments are tested, and whether active testing runs against production at all. Many teams review production configuration read-only and run intrusive checks in a staging project that mirrors it. If production is tested, agree on timing, monitoring owners and a stop condition before work begins.

GKE and serverless components

Include Google Kubernetes Engine clusters, Cloud Run services, Cloud Functions and API gateways only if they are named in scope. Each adds its own control plane settings, workload identities and entry points, and each may need a separate benchmark review. Confirm whether the assessment covers the workloads running inside them or only their cloud configuration.

Rules of engagement

Google does not require notice before a penetration test of your own Google Cloud infrastructure, but the test must follow Google's Acceptable Use Policy and Terms of Service and affect only your own projects. Denial of service testing is excluded from every engagement. Put the permitted techniques, testing windows, source addresses and escalation contacts in the written scope.

How the assessment runs, phase by phase

The sequence moves from written scope and rules of engagement through configuration review and targeted testing to validated findings, a report and a retest, so each stage produces evidence the client can check. Each phase has a defined output before the next one begins.

Agree scope and written rules of engagement
The provider and the client agree in writing which Google Cloud organization, folders and projects are in scope, which identities and tenants the testers may use, and which activities are excluded. Google Cloud does not require notice before a penetration test of your own infrastructure, but the work must follow Google's Acceptable Use Policy and Terms of Service and affect only your own projects, so the rules of engagement record those limits. Confirm with the provider whether any service in scope has its own testing restrictions. The step closes when the client signs off the scope document and names a technical contact who can stop testing.
Collect configuration evidence across the organization
The team gathers read-only evidence from the organization, folder and project hierarchy, including IAM policy bindings, service account inventory and key age, firewall and network configuration, storage bucket settings, and audit log sinks and retention. Access is granted under a dedicated review identity with read permissions, and every collection command and export is logged. The step closes when the evidence set is complete for each project in scope and the client confirms that no in-scope project was left out.
Review configuration against CIS GCP control groups
Using the CIS Google Cloud Platform Foundation Benchmark at version 5.0.0 as the review basis, the team maps the collected evidence to the benchmark's control groups, covering identity and access, logging and monitoring, networking, and storage. Each control is marked as pass, fail, not applicable or needs client input, with the reason written beside it. Findings are not limited to benchmark checks, since configuration that technically passes can still expose a risky path. The step closes when every in-scope control has a recorded result and a short justification that the client can trace back to the evidence.
Map attack paths from the configuration review
The team combines failed controls into likely attack paths, such as a service account with broad project roles that can impersonate a more privileged account, a public storage bucket holding sensitive data, or a publicly reachable service with weak authentication. This analysis is done on paper and in the evidence first, so that testing focuses on paths that matter to the client's business. The step closes when a short list of candidate paths is agreed with the client, with the owner of each affected project identified.
Test identified paths within the agreed limits
Testers validate the shortlisted paths in a controlled manner, for example confirming whether a identity can reach a permission it should not hold, whether a storage location is readable from outside, or whether a reachable service accepts requests it should refuse. Denial of service, flooding and any activity against data or tenants outside the client's own projects are excluded. Each test is recorded with timestamps, the account used and the result, and any sensitive data encountered is handled as the rules of engagement require. The step closes when each path has a recorded outcome of confirmed, not confirmed or blocked.
Validate findings and rate severity
Each confirmed issue is reproduced once more by a second tester where practical, and then rated for severity using the client's own criteria, with the likelihood and business impact stated alongside the technical risk. Findings that could not be confirmed are kept in the report with the reason, so the client can see what was checked. The step closes when every finding has a reproducible description, an evidence reference, a severity rating and a named remediation owner on the client side.
Deliver the report and walk through remediation
The report contains an executive summary, the scope and rules of engagement as agreed, the CIS control results, the confirmed attack paths, the findings with evidence, and recommended fixes written so the client's engineers can act on them. The provider meets the client's technical and risk owners to explain the findings and agree a remediation order. The report is an input to the client's own assessment or customer review, and it is not an audit report or certification, which an independent auditor issues. The step closes when the client accepts the report and the remediation plan is recorded.
Retest fixed findings and close the engagement
After the client reports that fixes are in place, the team repeats the original checks for each finding and reviews the changed configuration. A finding is closed only when the retest shows the issue is resolved, and any partial fix is recorded as open with the remaining gap. The closing record lists every finding with its final status and the evidence used to close it. Ask the provider whether a retest is included in the quote or priced separately, since that changes how much of the cost is one-time. The step closes when all findings have a final status and the client holds the closing record.

How IAM bindings and service account keys become attack paths

Identity and access management is where most Google Cloud findings start, because a single over-broad binding can give one identity control over many projects. The primitive roles, Owner and Editor, predate the finer predefined roles and still appear in many environments. When either is granted at the organization or folder level, it inherits downward into every project beneath it, so a binding that looked narrow at the top can reach resources nobody reviewed. A review of IAM policy inheritance at the organization and folder level is therefore the first step, not a project-by-project check.

Default service accounts and user-managed keys add a second layer. Depending on which APIs a project enables, default service accounts may hold broader roles than the workloads using them need, and a compromised workload inherits those roles. User-managed service account keys are long-lived credentials that persist until someone deletes them, and they often sit in repositories, CI variables or virtual machine images. Reviewers check which keys exist, their age, who created them and where they are used, and confirm with the client whether the organization policy restricting key creation is enforced. Impersonation rights form the third layer: a grant that lets one identity act as a service account, or generate its tokens, can turn a low-privilege user into a high-privilege workload. Confirm the exact permissions that allow impersonation in your own environment before assuming they are limited.

Reviewers map these elements into escalation paths: starting identity, the bindings it holds directly or through groups, the service accounts it can impersonate, and the resources those accounts reach. The output is a ranked set of paths with the evidence for each step, which lets the client fix the shortest routes first. A remediation plan should specify the owner of each binding, replacement predefined or custom roles, a key rotation or deletion schedule, and a recurring access review. Ask the provider to show how the plan will be validated, and confirm which checks the CIS Google Cloud Platform Foundation Benchmark covers so that results can be traced to recognized control IDs.

Which weaknesses the assessment looks for and why they matter

This table maps each weakness category the assessment checks against the CIS Google Cloud Platform Foundation Benchmark (version 5.0.0) to its appearance in a project, its business risk and the evidence the report should contain. Read each row as a finding to confirm or rule out in your own environment, and use the evidence column to judge whether a report will hold up to your auditor or customer.

Weakness category	What it looks like in a GCP project	Business risk and report evidence
Over-broad IAM bindings	Primitive roles such as Owner or Editor granted at organization or folder level, or broad predefined roles bound to groups and users who do not need them	Excess access enables lateral movement and data exposure. Report should list each binding, the principal, the inherited scope and the least-privilege alternative.
Long-lived service account keys	User-managed JSON keys that never rotate, copied into repositories, CI variables or laptops, with no owner recorded	A leaked key grants persistent access that survives password resets. Report should show key age, creation date, location and whether workload identity could replace it.
Default service accounts in use	Compute Engine or GKE workloads running as the default compute service account, which often carries the Editor role	Any compromised workload inherits broad project rights. Report should identify each workload, the attached identity and the roles it holds.
Firewall rules open to the internet on administrative ports	Ingress rules allowing 0.0.0.0/0 on SSH, RDP or database ports, or rules with broad priorities that override intended denies	Direct administrative access from the internet invites brute force and exploitation of exposed services. Report should list each rule, the affected instances and the network tags used.
Public Cloud Storage buckets	Buckets or objects granted to allUsers or allAuthenticatedUsers, or uniform bucket-level access disabled on sensitive data stores	Unintended disclosure of customer or regulated data. Report should list affected buckets, sensitivity of contents where known, and the IAM and public access prevention settings.
Missing or disabled Cloud Audit Logs	Admin Activity or Data Access logs not enabled for relevant services, log sinks absent, or retention too short for incident investigation	Without logs, intrusions cannot be scoped or proven. Report should show log configuration per project, sink destinations and retention settings.
SSRF exposure to metadata endpoints	Workloads that fetch user-supplied URLs and can reach the metadata server at 169.254.169.254, and workloads that do not enforce the metadata concealment controls	A server-side request can return access tokens for the workload's service account. Report should describe the request path tested, the identity exposed and the egress and metadata controls confirmed.

How a Google Cloud assessment differs by architecture

A single-project estate usually contains a handful of Compute Engine virtual machines, a managed database such as Cloud SQL, a storage bucket or two, and a default or custom VPC. Scope is simple to draw because one project boundary holds nearly everything, so the review can cover the full CIS Google Cloud Platform Foundation Benchmark in one pass. Access is usually granted to a small group of engineers, which makes over-broad project-level roles and long-lived service account keys the most common findings. Testing focuses on IAM bindings, firewall rules that expose management ports, instances with public IP addresses, database network authorization and whether audit logs are enabled and retained. Google states that customers do not need to notify Google before testing their own infrastructure, but tests must stay within their own projects and follow the Acceptable Use Policy and Terms of Service. Illustrative example: a single project with one database reachable from a broad authorized network range would be tested first for that exposure, then for the roles that can change it.

Project-level roles: check whether owner or editor roles are granted to people and service accounts that do not need them.
Service account keys: confirm which keys exist, their age and where they are stored.
Firewall rules: test whether administrative ports are reachable from the internet.
Storage exposure: verify that buckets are not readable by public principals.
Audit logging: confirm that Admin Activity and relevant Data Access logs are enabled and exported.

Before signing, confirm which projects, regions and managed services the quote covers, and who in your team will approve testing windows.

Frameworks and customer reviews that expect cloud configuration testing

This table compares the frameworks and customer reviews that ask for cloud configuration evidence, what each one expects a Google Cloud environment to show, and where evidence usually falls short. Use it to decide which assessment outputs your auditor or customer will need. DeployOpen prepares the evidence, but independent auditors and certification bodies issue any report or certification.

Framework or review	What it expects for Google Cloud	Evidence an assessor typically asks for
SOC 2 customer reviews	Access controls over cloud projects, logging and change monitoring that match the organization's stated service commitments	IAM role inventory, service account key records, audit log configuration and sample access review records; confirm the exact scope with your auditor
ISO/IEC 27001 customer reviews	Documented controls for access management, cryptographic keys, network security and logging, mapped to the organization's risk treatment	Configuration baseline results, exceptions with owners, and evidence that findings were tracked and closed; confirm the Annex A controls in scope
PCI DSS for cardholder environments	Segmentation of cardholder data environments, restricted access to storage holding account data, and logging of access to those resources	Firewall and VPC rule review, storage exposure results, audit log coverage for in-scope projects, and penetration test reports covering the cardholder environment
DORA, Article 21 access review	For systems supporting critical or important functions, access rights reviewed at least every 6 months (Delegated Regulation (EU) 2024/1774)	Dated access review records for IAM bindings and service accounts, approvals for changes, and removal records for unused identities
DORA, Article 10 vulnerability scanning	Automated vulnerability scanning of in-scope assets at least weekly (Delegated Regulation (EU) 2024/1774)	Scan schedules and results for compute and container assets, plus a record of how findings from configuration reviews were prioritized and remediated
CIS Google Cloud Platform Foundation Benchmark 5.0.0	Configuration checks across IAM, logging, networking and storage, used as a common baseline by many assessors	Benchmark pass and fail results by control ID, documented exceptions with compensating controls, and remediation dates
Customer security questionnaires and reviews	Evidence that cloud configuration is tested on a defined schedule and that the tester was authorized within Google Cloud's testing terms	Test scope letter, dates, a summary report, and proof that testing affected only the client's own projects

What you receive and whether it satisfies your auditor or customer

A Google Cloud assessment produces several linked outputs, each aimed at a different reader. The executive summary serves leadership, the findings and mapping serve engineers and assessors, and the scope letter serves customers and auditors who need to know what was tested and how.

Executive summary

A short document for the board, CISO and risk committee that states the overall posture of the projects and organization in scope, the most significant weaknesses and the decisions needed to fix them. It should name the projects, folders or organization node covered and the date of the review, so it can be read without the technical report. Check that it states what was not tested, such as workloads outside the agreed scope or third-party services, so leadership does not assume broader coverage than was delivered.

Findings with severity and resources

Each finding names the affected resource by project, resource type and identifier, explains the weakness category, and assigns a severity with the reasoning behind it. Severity should reflect exposure and the value of the affected data or identity, not just the technical label. Ask for the rating method in writing and check that every finding lists reproducible evidence at a level your engineers can verify without the tester running further exploitation.

CIS GCP benchmark mapping

A table that maps each finding and each passed control to the relevant recommendation in the CIS Google Cloud Platform Foundation Benchmark, version 5.0.0. This gives assessors a common reference point and shows which recommendations were checked, failed, or not applicable. Confirm that the report states the benchmark version used, because recommendations change between versions and an outdated mapping will not match a current audit.

Defensive attack-path write-ups

Where several weaknesses combine, the report describes the attack path at a conceptual level: for example, a service account with broad project rights that is also reachable from an internet-facing workload. Each write-up explains the conditions that make the path possible and the control that breaks it. It does not contain working exploit steps, payloads or commands. Ask for this level of detail explicitly so that engineers understand why a finding matters without receiving a reusable attack playbook.

Remediation guidance

For each finding, the report gives a specific corrective action, such as removing a basic role binding, replacing a long-lived service account key with workload identity federation, or restricting an ingress firewall rule to named sources. Good guidance names the Google Cloud setting to change and the owner of that change. Ask whether the remediation advice is prioritized against your deployment timeline and whether it covers infrastructure-as-code changes so fixes do not drift back.

Retest results

After your team fixes the findings, a retest confirms whether each one is closed and records the evidence. The retest result should list each original finding with its status, the date checked and what changed. Clarify with the provider whether retesting is included in the fixed-scope quote or priced separately, and whether it is limited to the original findings or covers new configuration changes made in the meantime.

Scope and method letter

A letter that describes the scope, the projects and services covered, the method, the dates and the tools category used. Customers can use it in a security questionnaire and auditors can use it as evidence of the work performed. It describes the work and is not an attestation or certification: it does not state that your environment is compliant, and only an independent auditor or certification body can issue that conclusion. Confirm with your auditor which format they accept before the engagement starts.

What your team should prepare before the assessment starts

Start by confirming read-only audit access to every organization, folder and project in scope before the kickoff meeting. For a Google Cloud assessment this usually means viewer-level roles across the resource hierarchy, plus access to IAM policies, service account listings, firewall rules, storage bucket configuration and Cloud Audit Logs. Agree in writing which folders and projects are in scope and which are out, because the reviewer should not discover a project during testing that nobody listed. Name one technical contact who can answer questions about architecture, owners of each project and the intent behind unusual bindings, and name escalation contacts for anything that could affect production. Confirm the exact people and hours for each role with your own team, since the written scope should show them before work begins.

Agree the testing windows and tell your own security operations center about the assessment in advance. Scanning and configuration review generate a burst of API calls, failed authentication events and unusual network traffic, and a SOC that has not been told may open an incident and start containment against the assessor. Share the source addresses or identities the testers will use, the dates and the time windows, and a named person who can confirm that an alert is expected. Also list any change freezes that cover your Google Cloud estate, such as release trains or month-end processing, so that assessors do not interfere with a planned deployment. Ask your assessor to record each activity against those windows so the timeline can be matched to your logs later.

Prepare a list of approved test accounts and confirm that testing stays inside your own projects. Google Cloud states that customers do not need to notify Google before penetration testing their own infrastructure, but tests must follow the Acceptable Use Policy and Terms of Service and affect only the customer's own projects. Any component that belongs to a third party, such as a managed service run by a vendor, a partner's tenant or a SaaS integration, follows that provider's own testing rules, and you should confirm those rules before scoping them in. Ask your assessor to state how it will handle a finding that points outside your projects, such as a service account key that grants access to another organization, so that the work stops at the boundary and the question goes back to you.

What to check when choosing a Google Cloud assessment provider

A Google Cloud assessment is only as useful as the provider's method, scope discipline and reporting. The cards below cover the questions that separate a credible engagement from a generic scan, from benchmark mapping to what happens after the report is delivered. DeployOpen is not a Google partner or certified provider, so ask every provider, including us, to show how their work meets these points.

Benchmark version mapping

Ask which version of the CIS Google Cloud Platform Foundation Benchmark the provider assesses against and how each finding maps to a recommendation number in that version. The current version is 5.0.0, and older versions renumber or retire controls, so a report that cites an unspecified version is hard to reconcile with your auditor's evidence. Ask for a sample finding that shows the control reference, the observed state and the affected project. Confirm whether checks not covered by the benchmark are labeled separately.

Testing within Google's terms

Google Cloud does not require notice before you test your own infrastructure, but the work must follow the Acceptable Use Policy and Terms of Service and affect only your own projects. Ask the provider how they confirm that every target belongs to your organization, and how they avoid testing shared services or other tenants. Ask how denial of service and high-volume traffic are excluded from the scope in writing. Confirm which activities need extra approval before they are planned.

Credential and evidence handling

Assessments often need read-only service account access, and some tests touch secrets or exported logs. Ask where credentials are stored, who can use them, how long they remain valid and whether they are revoked at close. Ask how evidence containing personal data or security configuration is encrypted, retained and deleted, and whether it stays inside your environment or your agreed systems. A provider that cannot answer these questions in specific terms is not ready for production access.

Fixed scope in writing

Ask for a written scope that names the organization, folders, projects, services and regions in the assessment, along with the excluded resources and the testing windows. Check that the statement of work lists the deliverables and that any change to scope requires a written change request. Ask how the provider handles a project discovered during testing that was not in scope. An open-ended scope makes both cost and findings hard to defend to an auditor.

Report contents and severity

Ask for a sample report before you buy. A useful report separates configuration findings from exploitable attack paths, explains the business impact of each, and gives a remediation step that your platform team can apply. Check whether the findings are tied to project IDs and resource names so your engineers can locate them. Confirm whether the report includes an executive summary for leadership and a technical annex for engineers, and whether it is written to be shared with an external auditor.

Retest and experience with your architecture

Confirm the retest policy in writing: whether one retest is included, how long after delivery it must be requested and whether it covers all findings or only the high ones. Then ask for experience with your architecture, such as GKE clusters, Cloud Run, Cloud Functions behind API Gateway, or a multi-organization hierarchy with shared VPCs. Ask which Google Cloud services the team has assessed and how it stays current with Google's service changes.

Questions buyers ask about Google Cloud security assessments

How much effort does a Google Cloud security assessment take, and what drives it?

Effort depends mostly on how many projects, folders and organization-level settings are in scope, how many services each project uses, and how mature the existing IAM and logging configuration is. Each project needs its IAM bindings, service accounts and keys, firewall rules, storage settings and audit log configuration checked against the CIS Google Cloud Platform Foundation Benchmark, which is currently at version 5.0.0. Environments with many projects, custom roles or hybrid connectivity take longer. Ask any provider for a written scope listing projects, services and the benchmark sections to be covered, then compare the quote against that list. DeployOpen does not publish a price list; a quote follows from the written scope.

How long does a Google Cloud security assessment take?

Duration follows from the scope. A configuration review of a small number of projects moves faster than a review across an organization with many folders, shared VPCs and centralized logging. Time is also spent on access to the environment, clarifying ownership of projects, and walking through findings with your engineers. Ask for the timeline in the written scope and confirm which dates depend on your team's responsiveness. Most DeployOpen engagements are fixed-scope, so the agreed deliverables and schedule are fixed before work starts.

What does the work need from our team?

Expect to provide a named technical contact, read-only or auditor-level access to the agreed projects and organization settings, and a list of who owns each project. Your team should also supply current IAM policies, logging and retention settings, and any documented exceptions, such as service accounts that intentionally hold long-lived keys. Someone must be available to answer questions about business workloads, because a finding can be a deliberate design choice. Confirm with the provider exactly which access levels they need and how credentials are issued, rotated and revoked at the end of the engagement.

Can our own staff run a CIS Google Cloud review themselves?

Yes, a capable internal team can work through the CIS Google Cloud Platform Foundation Benchmark, and the CIS Benchmarks are freely available in PDF for non-commercial use. The harder parts are interpreting controls against your architecture, testing whether a configuration is actually effective rather than only present, and keeping evidence in a form an assessor will accept. Internal reviews also face independence concerns when the same people build and assess the environment. Many organizations use internal staff for continuous checks and bring in an external reviewer for periodic assessment or before an audit.

Do we need to notify Google before testing our Google Cloud environment?

Google states that customers do not need to notify Google before penetration testing their own Google Cloud infrastructure. You must still follow the Acceptable Use Policy and Terms of Service, and make sure tests affect only your own projects. A configuration review is passive and reads settings, but any active testing should be scoped so it cannot reach other tenants or Google-owned systems. Confirm the target list in writing, including any third-party SaaS or on-premises systems connected to the projects, because those may have their own testing rules. The Google Cloud notification guidance is the right starting point for this question.

Will the report satisfy an auditor or a customer's security review?

A DeployOpen report documents what was tested, the methodology, the benchmark sections covered, the findings and the agreed remediation path. It can serve as evidence for an auditor or a customer's security review, but it is not an audit report, attestation or certification. DeployOpen prepares systems, controls and evidence for compliance assessments; independent auditors and certification bodies issue the conclusions. Ask your auditor or customer in advance what evidence format they accept, which benchmark version they reference, and whether they require a retest before accepting closure of findings.

How does retesting work after findings are fixed?

Retesting checks whether agreed findings were remediated. It is normally scoped in the original statement of work or as a separate fixed-scope step, so confirm whether it is included and how many rounds are covered. Retesting should compare the current configuration against the same benchmark controls and record the new evidence. For ongoing assurance, DeployOpen offers retainers for continuous testing and support, which can cover recurring reviews after the initial assessment.

How does a Google Cloud assessment differ from an AWS or Azure assessment?

The methodology is similar, since each is a configuration review against a CIS benchmark, but the vocabulary and structure differ. Google Cloud uses organizations, folders and projects, IAM bindings on resources and service account keys, while AWS uses accounts, roles and policies, and Azure uses subscriptions, role assignments and Entra ID integration. Benchmark versions also differ: the CIS Amazon Web Services Foundations Benchmark is at version 7.1.0, the CIS Microsoft Azure Foundations Benchmark at 6.0.0 and the Google Cloud benchmark at 5.0.0. Each provider also publishes its own testing rules, so active testing rules must be checked separately for each cloud.

How DeployOpen scopes, tests, reports and retests Google Cloud environments

DeployOpen approaches Google Cloud security assessment as a fixed-scope engagement, agreed in writing before any testing starts. We review the organization and project configuration against the CIS Google Cloud Platform Foundation Benchmark, then test the findings that matter in your own projects, and hand over documented results your team can act on.

How we scope

We agree in writing which organization, folders and projects are in scope before any testing begins.
The written scope names IAM, service account, network, storage and audit logging areas, with the CIS benchmark version used as the reference.
We confirm that all testing stays within your own projects and follows Google Cloud's Acceptable Use Policy and Terms of Service.

How we build

We collect read-only configuration evidence first, so the review reflects how your projects are actually set up.
Testing covers IAM bindings, service account keys and exposure paths, firewall rules, storage access and log coverage.
Findings are validated by hand, with risk noted for each item and false positives removed before reporting.

How we hand over

You receive a written report mapping each finding to the relevant CIS Google Cloud Platform Foundation Benchmark recommendation.
Each finding includes affected resources, evidence, business impact in plain terms and a prioritized remediation path.
We walk your platform and security teams through the results and confirm which items need retesting after fixes.

How we support

Retesting of agreed findings is scoped separately, so you can verify fixes before the next review.
Ongoing support, configuration reviews and continuous testing are available as a retainer for teams that change projects often.
Ask any provider to confirm how they handle evidence, access to your projects and the format of the final report before signing.