Can you run CMMC on Google Cloud and Google Workspace?
Yes, a defense contractor can hold CUI in Google Cloud or Google Workspace, but the answer depends on which offerings appear in your System Security Plan. Google says that Google Cloud and Google Workspace maintain FedRAMP High authorization for in-scope services, publish C3PAO CMMC attestation letters for each, and provide a NIST SP 800-171 compliance attestation letter and CMMC implementation guides. Those documents support your assessment, but they do not transfer your obligations. The customer responsibility matrix still assigns you the controls that Google does not perform, such as your user identities, access approvals, endpoint settings, and the handling of exported CUI. An assessor will test the cloud claim in two steps. For a FedRAMP High claim, the assessor checks the FedRAMP Marketplace entry by provider, service offering, impact level and status, and confirms that the exact offering named in your SSP is listed. If you rely on an equivalency claim instead, the assessor checks that the body of evidence is complete, intact and current under the DoD CIO equivalency policy, without judging the offering against FedRAMP Moderate. Confirm with Google which Workspace apps and Cloud services are in scope, because an unlisted service cannot be used to hold CUI on the strength of a general attestation letter.
Your own infrastructure remains in scope either way. Endpoints, identity connectors, browsers, network paths into the tenant, and any on-premises system that syncs or exports CUI are assessed as part of your environment. DeployOpen can prepare the tenant configuration, identity integration, logging, and evidence that map to your customer responsibility matrix, and it can document how each shared control is split between you and Google. Only an independent C3PAO or assessor issues assessment results, and a self-assessment is your own determination. Ask your assessor early which evidence they will accept, and request a written scope before any configuration work begins.
How assessors verify FedRAMP status or equivalency
The assessor checks the cloud provider's authorization against the FedRAMP Marketplace or the DoD equivalency evidence, then confirms the exact service named in your System Security Plan is covered. Each check produces a file the assessor keeps in the assessment record.
Identify the cloud offering named in the SSP
You, as the contractor, name each Google Cloud or Google Workspace service that stores, processes or transmits CUI in your System Security Plan. The assessor starts from that list, not from the marketing name of the platform. Confirm that the provider, service offering and impact level in your SSP match the exact services you use. The output is the scoped service list that every later check tests against.
Search the FedRAMP Marketplace by provider
The assessor searches the FedRAMP Marketplace for the provider and reviews each listed authorization. The check covers provider, service offering, impact level and status, and the assessor records the result for each service in scope. Confirm that the authorization you rely on is at the FedRAMP Moderate level and shows a current status. The output is a dated Marketplace record for each offering.
Match the offering to the SSP entry
The assessor confirms that the specific offering named in your SSP appears on the Marketplace listing. A provider-level authorization does not cover a service the provider has not listed, so a service missing from the list falls outside the authorization. You should ask Google which services are included in the authorization boundary before you finalize the SSP. The output is a service-by-service match between your SSP and the Marketplace record.
Review the equivalency evidence for a claimed FedRAMP Moderate equivalent
If a provider claims FedRAMP Moderate equivalency rather than a Marketplace listing, the assessor reviews the body of evidence the provider supplies under current DoD CIO equivalency policy. The assessor checks that the evidence is complete, intact and within the required periodicity. The assessor does not re-evaluate the offering against FedRAMP Moderate. The output is a completeness and currency determination for the evidence file.
Collect Google's attestation and implementation documents
You obtain the documents Google publishes for CMMC, including the C3PAO CMMC attestation letters for Google Cloud and Google Workspace, the NIST SP 800-171 compliance attestation letter and the CMMC implementation guides. The assessor checks that these documents match the services and versions in your SSP and that they are current. Treat these letters as supporting evidence, not as a substitute for your own assessment of your environment. The output is a versioned set of provider documents filed with your assessment evidence.
Verify the customer responsibility matrix is current
The assessor checks that the provider's customer responsibility matrix is current, names every party with security responsibilities and covers each in-scope requirement the provider performs wholly, partly or jointly. You confirm that your own SSP documents or references the matrix and assigns each remaining requirement to your organization. Any gap between the matrix and your SSP becomes a finding. The output is a reconciled matrix that shows who owns each requirement.
Confirm your on-premises connections remain in scope
The assessor confirms that your own infrastructure connecting to Google Cloud or Google Workspace stays inside the assessment scope, whatever the provider's authorization. This includes endpoints, identity connectors, network boundaries and administrative workstations you control. You document these components in the SSP and show how they meet the requirements you own. The output is a scoped inventory of your side of the connection, linked to the provider evidence.
Google Cloud versus Google Workspace for CUI
Google Cloud services that store, process or transmit CUI form the infrastructure layer of your environment. Google says its in-scope services maintain FedRAMP High authorization, and it publishes C3PAO CMMC attestation letters, a NIST SP 800-171 attestation letter and implementation guides for Google Cloud. Those documents describe Google's side of the shared model. Your SSP must still name each service that holds CUI.
- Offering-level listing: Check each Google Cloud service in your boundary against the FedRAMP Marketplace entry, which lists the provider, service offering, impact level and status. Coverage of a product area is not enough on its own.
- Attestation letter scope: Read the C3PAO letter for the version and scope it covers, and confirm that every service you use falls inside it.
- Customer responsibility matrix: Obtain the current matrix and map every requirement Google performs wholly, partly or jointly to a named party. Your SSP must reference it.
- Your connections to the cloud: Admin workstations, identity connectors, backup agents and egress paths on your premises stay in your assessment scope.
Before the assessment, request the current matrix and offering list from your Google contact, then match each named service to the Marketplace entry and to your SSP.
Workspace applications that carry CUI in email, files, documents and chat are where most contractors first meet the question of scope. Google states that Workspace maintains FedRAMP High authorization for in-scope services and publishes the same set of CMMC materials used for Google Cloud, including C3PAO attestation letters, a NIST SP 800-171 attestation letter and implementation guides. Those materials do not configure your tenant, so the settings that govern CUI remain your responsibility.
- Named applications: List each Workspace application that stores or transmits CUI, such as mail, file storage, documents and chat, and confirm it appears in the offering scope Google documents.
- Tenant configuration: Record which administrator roles can change sharing, retention, external access and data location settings, and export those settings as evidence.
- External collaboration: Identify every route by which CUI leaves the tenant, including subcontractor sharing, guest accounts and mobile clients, and document a control for each route.
- Logging and retention: Confirm that audit log export and retention settings match what your SSP commits to, and test that logs are retrievable.
Ask for the Workspace implementation guide and attestation letter, then test sharing, retention and logging in your tenant against each SSP entry that cites them.
Most contractors run hybrid designs, in which CUI moves between Google Cloud, Workspace and on-premises systems. Under the scoping rule in 32 CFR 170.19, the assessment boundary follows the CUI and the connections that carry it. Google's attestations cover the services Google runs, so every flow that crosses into or out of those services needs its own documentation in your SSP.
- Boundary diagram: Draw every flow between on-premises systems, Google Cloud projects and Workspace tenants, including identity sync, backups and exports. Any connection that carries CUI is in scope.
- Split responsibility: Where Google and you both meet a requirement, record both parties in the matrix and state in the SSP what you retain.
- Identity across both: Confirm that one authoritative identity source and one MFA configuration govern Workspace, Google Cloud and your on-premises systems, and that the SSP describes it accurately.
- Evidence from both sides: Use Google's letters and guides as inputs, and produce your own configuration exports, logs and change tickets for your share of each requirement.
Trace one CUI file from creation to deletion through every system it touches, and confirm that each hop appears in the diagram, the matrix and the SSP.
Which controls stay with you on Google
Google's FedRAMP High authorization and attestation letters cover the provider's side of the environment, not yours. The cards below cover the controls your organization still configures, operates and evidences, and what the customer responsibility matrix in your SSP should say about each.
Identity and MFA configuration
You decide how users sign in to Google Cloud and Google Workspace, which administrator roles exist, and whether multifactor authentication is enforced for every privileged account. The customer responsibility matrix should name who configures identity federation, conditional access and MFA enrollment, and which requirements in the IA family depend on those settings. Verify the matrix against the current identity settings in your tenant, not against the version you signed months ago. Confirm the exact responsibility split with Google's CMMC documentation.
Access reviews and least privilege
Google provides the IAM mechanisms, but you define who holds which roles, approve exceptions and remove access when people leave or change jobs. Assessors will look for dated review records showing that accounts and group memberships were checked against the CUI authorization list. The matrix should state who runs the reviews, how often, and where the records are kept. Ask Google which of its responsibilities touch account lifecycle so there is no gap between the two lists.
Endpoint and device management
Workspace can enforce device policies, but the endpoints that reach CUI, including laptops, phones and any unmanaged browsers, are your responsibility. Decide which devices may access CUI, how they are enrolled, and how a lost or noncompliant device is blocked. The matrix must name the management tool and the party operating it. Confirm with Google which device controls Workspace provides and which you must supply through your own endpoint platform.
Log retention and review
Google collects audit and admin activity logs, but retention periods, export destinations and who reviews the events are configuration choices you make. Route logs to a store you control, set retention to meet your contract and SSP commitments, and document who reviews alerts and how review is evidenced. The matrix should separate what Google logs from what you must export, correlate and protect. Check the retention settings in your own project or tenant during each assessment preparation cycle.
Data sharing and external collaboration
Google Drive and Sites can share files with external domains, anyone-with-the-link access and third-party apps. Each of these settings can move CUI outside the authorized boundary, so you must restrict them to approved domains and document the policy. The matrix should name the administrator who owns sharing settings and the review process for third-party app grants. Verify the configured settings directly in the admin console, because the default state may not match your policy.
Encryption key choices
Google encrypts data at rest by default, but the choice between Google-managed keys, customer-managed keys and externally held keys determines who can access plaintext data. Assessors will expect you to show which key model protects CUI, that the cryptographic modules meet the FIPS-validated requirement, and who controls key rotation and revocation. The matrix must state the key model in use and the party responsible for key lifecycle. Confirm the FIPS-validated modules and key options for your specific services with Google.
What stays in scope on your side of the connection
Choosing Google Cloud or Google Workspace does not remove your own infrastructure from the assessment. Under 32 CFR 170.16(c) and 170.17(c), the contractor's on-premises infrastructure that connects to a cloud or external service provider stays in scope, whatever the provider's authorization. Google's FedRAMP High authorization and its CMMC attestation letters cover the services Google operates, not the endpoints, identity connectors, network paths and administrative tooling you run. Before you estimate effort, run a scoping review that traces every path by which CUI enters, leaves or is administered in the Google environment, and confirm the result with your C3PAO or assessor, since the boundary is decided by the assessment, not by the vendor.
In practice, the items most often left out are the endpoints that open Workspace or the Google Cloud console, including laptops, browsers, mobile devices and any virtual desktops. Each one needs to meet the Level 2 requirements that apply to it, such as access control, configuration management, malicious code protection and encryption of CUI at rest on the device. Identity connectors deserve the same attention. If you synchronize directory accounts or federate sign-in from an on-premises directory into Google, the synchronization servers, service accounts and the directory itself are in scope, along with the administrators who can change them. Network egress from your offices and data centers, including proxies and firewall rules that permit traffic to Google endpoints, belongs in the boundary diagram as well.
Admin workstations and any on-premises copies of CUI need separate treatment. Privileged administrators who manage Google Cloud projects or Workspace tenants should work from hardened, dedicated devices, and those devices and their logs fall under your audit and access controls. Exports, backups, downloaded files and local sync folders create on-premises copies that the Google service does not protect for you. Ask your scoping reviewer to list every copy and decide whether it should be eliminated, moved inside the enclave or brought into scope with its own controls. Document each decision in your system security plan, and record which parts of the matrix Google covers so the assessor can see where your responsibilities begin.
What a Google-based CMMC environment costs to run
This table separates the cost components of a Google-based CMMC environment by who is paid, whether the cost is one-time or recurring, and what drives it up. Use it to structure a request for quote, and treat every figure as something to obtain from Google, your implementation partner, your tool vendors and your assessor rather than as a planning number. Most of the recurring spend sits with the contractor, not with Google.
| Cost component | Who is paid | One-time or recurring | What drives the cost |
|---|---|---|---|
| Google Cloud and Workspace licensing and tiers | Google (or a reseller you contract with) | Recurring | Edition or tier that includes the in-scope services, user count, storage and any added security add-ons. Confirm in writing which tier covers your CUI services. |
| Implementation partner work on tenant configuration and evidence | DeployOpen or another implementation partner, under written scope | One-time build, plus optional retainer | Number of projects, admin consoles, identity integrations and evidence packages in scope. Fixed scope is agreed before work starts. |
| Internal staff time for control ownership | Your own staff (salary cost, not a vendor invoice) | Recurring | Number of controls you own outright, such as access reviews, incident handling, personnel screening and the system security plan. Ask your assessor which responsibilities remain yours. |
| Tooling such as SIEM, endpoint management and vulnerability scanning | Tool vendors or hosting providers | Recurring | Log volume, endpoint count, retention period and whether you buy a paid edition. Open-source options exist but may carry paid-edition limits to confirm. |
| Assessor fee for a Level 2 certification assessment | The C3PAO you engage, paid directly | One-time per assessment cycle | Scope size, number of systems and locations, and assessment duration. Request a fixed fee tied to a defined scope. Check current requirements, since Phase II status may affect whether this applies. |
| Google attestation letters and implementation guides | No direct charge identified in the supplied material | Not applicable as a separate line | Confirm with Google whether any access or documentation fee applies to your account before treating this as zero cost. |
What makes a Google CMMC project more or less expensive
Most of the effort in a Google CMMC project comes from how much evidence you must produce and how many parties must be assessed around it. The cards below cover the drivers that move that effort up or down, and the lever you control for each one.
Scope size in the SSP
Every user, device, Google offering and connected system named in your System Security Plan becomes something an assessor must examine. A Workspace tenant with a few groups and one Cloud project is far smaller than a tenant with many organizational units, multiple Cloud projects and shared drives holding CUI. Narrow the boundary by deciding early which users and data may touch CUI, and separate CUI workloads from general corporate collaboration where practical. Ask your consultant to show how each offering named in the SSP maps to requirements.
Third parties in scope
Each external service provider that stores, processes or transmits CUI, or that performs security functions for you, adds a customer responsibility matrix to review and a body of evidence to verify. Google is one provider, but a backup vendor, an email security gateway or a managed monitoring firm adds its own matrix and assessment questions. Inventory every third party before scoping. Ask which ones you can remove from the CUI path, because each one you keep requires documented responsibilities in your SSP.
Maturity of logging and access evidence
Assessors test whether logs exist, are retained, are reviewed and can be tied to a named user. If Google Workspace audit logs and Cloud Audit Logs are already exported to a central store with retention set and reviews recorded, evidence collection is mostly a matter of organizing it. If they are only viewed ad hoc in consoles, you will pay for log pipeline work, review procedures and months of records before the assessment. Confirm your retention settings, export paths and access review history now, since missing history cannot be recreated later.
Shared identity across Workspace and Cloud
When Workspace and Google Cloud use one identity source, one set of groups, one MFA policy and one joiner-mover-leaver process, you document and test those controls once and reference them from both environments. When they are separate, each identity store needs its own account lifecycle, MFA enforcement and access reviews, and assessors will test both. Decide the identity model before you configure either service, because changing it later means re-running evidence for every affected requirement.
Self-assessment or C3PAO assessment
A self-assessment is performed and affirmed by your organization, and the evidence stays internal unless challenged. A certification assessment by a C3PAO adds assessor fees, a formal evidence review, scheduling and the need for evidence in final form before the assessment begins. The required path depends on your contract. The Department of War's July 2026 suspension of Phase II paused the C3PAO requirement, so confirm with your contracting officer which assessment type applies to each contract and whether it changes during the review.
Customer responsibility gaps
Google's documentation and attestation letters cover the services in scope for Google, but your tenant settings, user management, data handling and on-premises connections remain yours. Each requirement that is shared with Google must be mapped to a clear split of responsibility. Gaps usually appear where administrators assume a default is correct, such as sharing settings, external collaboration or key handling. Review the matrix against your actual configuration, and fix mismatches before the assessor finds them.
From scoping to assessment with a Google environment
This sequence takes a defense contractor from a contract requirement to a documented Google-based CUI environment that is ready for a self-assessment or a C3PAO assessment. Each phase ends with a named output that the next phase depends on.
Confirm the contract requirement and level
Start by reading the contract clauses and solicitation to establish which CMMC level applies, whether a self-assessment or a C3PAO certification assessment is required, and whether the work touches CUI at all. Your contracts or contracting officer will confirm the current requirement, and the status of the Phase II suspension should be checked directly with the Department of War before you commit to a timeline. The output is a written statement of the required level and assessment type, signed off by the executive who will act as Affirming Official.
Scope the cloud offerings and on-premises boundary
Identify every Google Cloud service and Google Workspace application that will store, process or transmit CUI, and list your own on-premises systems that connect to them, such as endpoints, identity connectors and gateways. Confirm the scope with your assessor or C3PAO, since the contractor's on-premises infrastructure that connects to the cloud remains in assessment scope regardless of provider. The output is a scoping diagram and an asset list that shows which Google offerings are in scope and which systems stay under your control.
Pull Google's attestation letters and responsibility matrix
Download Google's CMMC attestation letters, its NIST SP 800-171 compliance attestation letter and its CMMC implementation guides from the Google Cloud CMMC compliance page. Confirm that each letter names the specific service and version you plan to use, then check the customer responsibility matrix against your scoping list. The output is a filed set of provider documents mapped to each offering in your boundary, with the dates you retrieved them recorded.
Verify FedRAMP status for each in-scope offering
For each Google offering that relies on FedRAMP authorization, check the FedRAMP Marketplace entry by provider, service offering, impact level and status, and confirm that the exact offering named in your system security plan is listed. If a claim rests on FedRAMP Moderate equivalency instead, collect the body of evidence and confirm it is complete, intact and within required periodicity under current DoD CIO equivalency policy. The output is a dated verification record for each offering that an assessor can reproduce.
Build and document your own controls
Work through the Level 2 requirements that Google does not perform for you, using the responsibility matrix to separate shared and customer-owned items. Assign owners for identity administration, endpoint configuration, logging review, incident handling, media handling and personnel screening, and configure the Workspace and Google Cloud settings you control, such as administrator roles, sharing rules and audit log retention. The output is a set of implemented controls, each with a named owner and a configuration record that you can show to an assessor.
Collect evidence in final form
Gather artifacts that show each applicable NIST SP 800-171A assessment objective is satisfied, such as exported configurations, access reviews, log samples, change tickets and training records. Store them in final form rather than as drafts, and tie each one to the requirement ID it supports. The output is an evidence index in which every in-scope requirement points to at least one final, dated artifact, with gaps logged as plan of action items.
Run the self-assessment or prepare the C3PAO handoff
Score your environment against the Level 2 requirements and record each as met or not met, recording only requirements whose objectives are fully satisfied as met. If a certification assessment applies, provide the assessor with the scoping diagram, the evidence index, the provider documents and the SSP, and let the C3PAO perform its independent review. The output is a completed self-assessment record with an accurate SPRS entry, or a documented package ready for the C3PAO.
Maintain the SSP and affirmations
Keep the system security plan current as Google services change, as your personnel and configurations change, and as the responsibility matrix is updated. Repeat the affirmation by the Affirming Official as the contract requires, and review the evidence index on a schedule your organization sets. The output is a current SSP, a dated affirmation record and a change log that together show the environment still matches what was assessed.
What to have in place before the assessor arrives
Google's attestations and FedRAMP status cover only part of the picture. The assessor will test your system security plan, your evidence for everything Google does not own, and how you track gaps you have not yet closed. Each card below is an item to verify before the assessment starts.
Current system security plan
Your SSP must describe the boundary that holds CUI, including every Google Cloud project or Workspace tenant in it, and must reference Google's customer responsibility matrix for the requirements Google performs wholly, partly or jointly. Check that the matrix you cite is the current version Google publishes, that each inherited requirement names who does what, and that your own responsibilities are written out in the SSP rather than left to the matrix. Also confirm that on-premises systems connecting to Google services appear in the boundary.
Verified FedRAMP Marketplace listing
For each Google offering named in your SSP, confirm on the FedRAMP Marketplace that the provider, the specific service offering, the impact level and the authorization status all match what you claim. Assessors check that the exact offering appears in the listing, so a broader product name is not enough. Record the check date and keep a screenshot or export in your assessment file, since authorization status can change.
Google attestation letters on file
Download Google's C3PAO CMMC attestation letters and its NIST SP 800-171 compliance attestation letter for the Google Cloud and Workspace services you use, and check that the services listed match your SSP. Google's CMMC implementation guides help you map its responsibilities to your requirements. Treat these documents as supporting evidence, not as proof that your environment meets Level 2, and confirm that you hold the versions that apply to your contract.
Final-form evidence for your requirements
For every one of the 110 Level 2 requirements that Google does not cover, you need evidence in final form, not drafts. Examples include access review records, configuration baselines for your endpoints, incident response procedures and training records. Assessors apply the NIST SP 800-171A objectives to each requirement, so check each item against those objectives and confirm that the evidence is dated, approved and tied to your environment.
Customer responsibility gap review
Compare Google's matrix line by line against your SSP and your own evidence. Look for requirements marked as shared where the split of duties is unclear, and for requirements that depend on settings you control, such as Workspace admin policies, Cloud IAM bindings, logging sinks and key management choices. Assign an owner to each item and record the setting or document that proves it. Assessors check that the matrix is current and names every party with security responsibilities.
Plan of action and milestones process
Where a requirement is not met at assessment time, your POA&M must describe the gap, the planned remediation, the owner and the schedule, and it must sit inside the rules for what can remain open. Check that the POA&M tracks requirements Google covers only partly, so that your open items do not overlap with the inherited controls you think you have. Review the POA&M on a fixed cadence so each entry has a current status and a closure record.
Common questions about CMMC on Google Cloud and Workspace
Does using Google Cloud or Google Workspace make my company CMMC compliant?
No. Google's services can support your CMMC Level 2 environment, but compliance applies to your organization and the systems in your assessment scope. Google publishes attestation letters and implementation guides for Google Cloud and Google Workspace, and those documents describe what Google covers. You still own the controls that depend on your users, devices, configurations, policies and on-premises infrastructure that connects to the service. An assessor will test your whole scope, and the customer responsibility work is where most of that ownership sits. Ask Google for its current CMMC documentation and map every requirement against your own system security plan before you rely on it.
Does FedRAMP High authorization mean Google Cloud meets CMMC?
No. FedRAMP High is a separate authorization for cloud services, and it does not replace the 110 Level 2 requirements in NIST SP 800-171 Rev. 2. Under CAP v2.0, assessors verify FedRAMP status on the FedRAMP Marketplace by provider, service offering, impact level and status, and they check that the specific offering named in your SSP is listed. Authorization of a service does not cover how you configure it, who you grant access to, or how you log, monitor and respond. Confirm that the exact service you use is in scope of the authorization before you cite it.
Is Google Workspace enough to store and email CUI?
Workspace can be part of a compliant design, but it is not enough on its own. Email and file sharing containing CUI must be limited to authorized users, protected in transit and at rest, logged, and governed by your access, retention and marking rules. Your organization must configure the tenant, enforce multifactor authentication, control external sharing, and document how CUI is marked and handled. Confirm with Google which Workspace edition, services and regions fall within the authorization you are relying on, and whether any feature you need is excluded from that scope before you move CUI into it.
What must my system security plan say about Google Cloud or Workspace?
Your system security plan must describe every cloud service in your CUI boundary, state which provider and service offering you use, and show how each requirement is met. For Google, it should reference the customer responsibility matrix and identify which requirements Google performs wholly, partly or jointly. Under 32 CFR 170.16(c) and 170.17(c), those matrix requirements must be documented or referenced in your SSP. It should also describe the on-premises infrastructure that connects to the cloud, because that stays in scope. Keep the SSP current, since assessors check that the evidence and descriptions match the system as it actually runs.
Do I need a C3PAO assessment now that CMMC Phase II is suspended?
It depends on your contracts and on current DoW guidance, so confirm both before planning. On 13 July 2026 the Department of War suspended CMMC Phase II, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. The DoW CIO page says implementation may only require self-assessments at Levels 1 and 2 for now, while the eCFR text still contains the original schedule. Ask your contracting officer which assessment your contracts require, and check the DoW CIO site for updates.
How much effort does the customer responsibility work take?
The effort depends on how much of your environment runs in Google's services and how many requirements Google performs wholly, partly or jointly. No public source gives a dollar figure or duration for this work, so ask your assessor or consultant to estimate it against your written scope. The work usually includes reviewing Google's CMMC documentation, mapping each requirement to a configuration or process you own, collecting evidence in final form, and keeping that mapping current after changes. Cost drivers include the number of users, the number of integrated systems, and how much on-premises infrastructure connects to the service. Ask for a fixed-scope quote that lists each deliverable.
Can DeployOpen issue a CMMC certificate for our Google environment?
No. DeployOpen plans, implements, configures and documents self-hosted open-source platforms and prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB, and only those independent assessors issue results. DeployOpen can help you prepare evidence and the system security plan for that assessment, and it can help you decide which parts of the work to outsource while keeping the assessor independent.
How DeployOpen prepares a Google environment for assessment
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For CMMC on Google Cloud and Google Workspace, we prepare the systems, configuration and evidence that your organization owns, while an independent assessor issues any findings or certification.
How we scope
- Map which Google services hold CUI and which of your on-premises systems connect to them
- Record which Google controls are inherited from the FedRAMP High and attestation documents, and which remain yours
- Agree the scope, deliverables and timeline in writing before any work starts, as fixed-scope engagements
How we build
- Configure identity, MFA, logging and access settings for your Google tenant and projects against the CMMC Level 2 requirements in scope
- Build self-hosted open-source tooling for controls Google does not cover for you, such as endpoint configuration and internal monitoring
- Test configurations and document each change so assessors can trace how each requirement is met
How we hand over
- Deliver a system security plan draft and a customer responsibility matrix that match your actual configuration
- Provide evidence packages mapped to each requirement, with a note on what your assessor must still verify
- Document operating procedures so your staff can run the environment, with your organization retaining ownership of controls and records
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Review configuration drift, evidence currency and changes to Google's documentation on a schedule you agree
- Confirm with Google and your assessor which current Google attestation and FedRAMP documents apply to your offering before relying on them
