Clear ownership. Practical cybersecurity.Atlant Security
Cyber/ManagedBY ATLANT SECURITY
Build your RFP Services RFP builder

GOOGLE WORKSPACE

Google Workspace security services: questions for your RFP

Define Workspace identity, sharing, connected applications and response ownership without confusing Workspace with Google Cloud.

Discuss your requirements
Illustrative security operations workspace overlooking a city

For the engagement owner. Scope the collaboration tenant separately from cloud infrastructure, then connect their identity and incident responsibilities.

Name the environment and its boundaries

Google Workspace and Google Cloud can appear in the same organisation but should not be treated as one undifferentiated service. Start the RFP with user population, Workspace edition, domains, identity integrations and device arrangements. State whether cloud projects also need review or belong to a different team. Describe how employees and suppliers collaborate at a high level. This lets a provider propose a Workspace workstream without silently adding infrastructure work or leaving a shared identity dependency outside the discussion. Unknowns should appear as discovery questions with an accountable owner.

Keep the platform boundary clear. Workspace: Accounts, collaboration and administration; Google Cloud: Projects, workloads and infrastructure; Shared identity: Name the cross-platform owner
Working model 01Keep the platform boundary clearIllustrative planning diagram. Adapt the decisions to your authorised scope.
Read diagram text
Workspace
Accounts, collaboration and administration
Google Cloud
Projects, workloads and infrastructure
Shared identity
Name the cross-platform owner

Describe collaboration before restricting it

Ask the service provider to understand where external collaboration is essential. A finance team exchanging documents with advisers may need a different exception process from an internal-only project group. Specify who can approve a sharing change, how a pilot is chosen and what evidence demonstrates that the business journey still works. Your requirement is an understandable control process, not the largest number of disabled settings. Record temporary exceptions, the business reason, an owner and a review date so that operational convenience does not become an undocumented permanent decision.

Illustrative business team reviewing service decisions together
Operational perspectiveAgree the service decisions with the people who own them.Generated illustrative setting; not a client location.

Include administrative and application ownership

Your inventory should cover administrators, identity providers, connected applications and the team responsible for managed devices. Do not upload account lists or application secrets to the initial enquiry. Ask for a structured review of access ownership and for a procedure to assess new integrations after onboarding. The proposal should explain what it needs to inspect, what it may change and what remains with your internal administrators. Where a supplier already manages Workspace, decide whether the new engagement reviews their work, implements agreed improvements or shares recurring responsibilities with them.

Review sharing in context. Business need: Describe who must collaborate; Control choice: Agree restrictions and exceptions; Verification: Check that the workflow still works
Working model 02Review sharing in contextIllustrative planning diagram. Adapt the decisions to your authorised scope.
Read diagram text
Business need
Describe who must collaborate
Control choice
Agree restrictions and exceptions
Verification
Check that the workflow still works

Make the response boundary explicit

A suspected account compromise can involve identity, collaboration, devices and a supplier. Require a handoff that identifies the first recipient, an alternative contact, available evidence and the person who can authorise containment. State the required operating hours as a buyer requirement. Ask the proposal to confirm which investigative capabilities and evidence retention depend on your actual edition and tooling. Do not turn a preferred response time into a claim that coverage already exists. An assessment, a recurring administrative review and an incident retainer are distinct service choices.

Define the provider relationship. Existing owner: Identify current administrator duties; New work: Assessment, changes or recurring review; Handoff: Record the decisions between teams
Working model 03Define the provider relationshipIllustrative planning diagram. Adapt the decisions to your authorised scope.
Read diagram text
Existing owner
Identify current administrator duties
New work
Assessment, changes or recurring review
Handoff
Record the decisions between teams

Test the service agreement with an example

Use a benign tabletop example: an administrator reports unexpected external access and is unsure which team owns the application. Walk through who receives the report, who checks the agreed evidence and who decides the next step. This can expose gaps in the service design before access is granted. Record the unresolved permissions, tooling and communication questions in the procurement log, then require answers in the statement of work.

Technical validation can complement a service programme when it has a separate purpose and authorisation. Our related guides explain application authorisation testing and clear technical procurement boundaries. Use that work to answer a defined assurance question, then assign the resulting actions to the service owners. These publications are part of the same Atlant Security portfolio.

Prepare a reviewable service request

Use the services RFP builder to record your platforms, current support, desired coverage and constraints. It produces a proposed shortlist with reasons, followed by an optional AI-assisted draft for your review. Unknown facts remain questions for the proposal. You can amend the draft and submit it to our team with your NDA or existing RFP. Do not include passwords, detailed production identifiers or confidential incident evidence. The tool does not activate a service or agree contractual terms.

Use a tabletop before onboarding. Report: Who receives the initial concern?; Investigate: Which evidence and access are available?; Decide: Who approves the next action?
Working model 04Use a tabletop before onboardingIllustrative planning diagram. Adapt the decisions to your authorised scope.
Read diagram text
Report
Who receives the initial concern?
Investigate
Which evidence and access are available?
Decide
Who approves the next action?

Primary sources

General information, not a compliance opinion. Confirm legal applicability and security service requirements for your entity and jurisdiction.

This guide and the related sector publications linked above are published by Atlant Security. Technical examples are planning examples, not claims about completed client tests.

Published by Atlant Security. Sources, editorial policy and corrections.

PUT THE GUIDANCE TO WORK

Choose your next step.

LET’S START A CONVERSATION

Define the scope.
Take the next step.

Your platforms, support needs and operating constraints. A useful starting point for your service proposal.

Discuss your requirements