Google Workspace Tenant Scan: Step-by-Step Security Assessment Guide

TL;DR

A Google Workspace tenant scan is a structured review of your organization's Admin Console settings, user accounts, sharing permissions, and connected apps to find security gaps before an attacker does. The highest-impact checks, in priority order: enforce phishing-resistant MFA for all admins, restrict Drive's default "Anyone with the link" sharing, audit third-party OAuth app access, review Super Admin account sprawl, and confirm DMARC is set to enforce (p=reject). Most organizations can complete a first-pass manual assessment in under two hours using only the Admin Console's built-in Security Health and Security Dashboard pages.

What this is

Google Workspace is secure by default in the sense that Google's own infrastructure is hardened — but almost every serious Workspace security incident traces back to configuration, not a flaw in Google's platform itself. "Anyone with the link" sharing left on by default, a third-party app granted broad Gmail access during a consent-phishing moment nobody remembers approving, an admin account still protected by SMS-based two-factor instead of a security key. None of these show up unless someone actually goes looking.

This guide walks through exactly how to run that review — a Google Workspace tenant scan — from the built-in Admin Console tools through to the specific settings that produce the most findings in real assessments.

A Google Workspace tenant scan is a systematic security assessment of a Workspace organization's configuration — authentication settings, user and admin account hygiene, Drive and email sharing permissions, connected third-party applications, and audit logging — performed either manually through the Admin Console or via automated SSPM (SaaS Security Posture Management) tooling. The goal is identifying misconfigurations and access risks that exist independent of any code vulnerability, since Workspace security failures are overwhelmingly configuration-driven rather than platform-driven.

The term "tenant" refers to your organization's isolated instance of Google Workspace — your specific domain, users, and configuration, distinct from Google's underlying shared infrastructure. A tenant scan doesn't test Google's platform; it tests how your organization has configured its slice of that platform, which is squarely your responsibility under Google's shared responsibility model.

Why it matters

A single point-in-time review only reflects the state of your tenant on the day you ran it. The gap between "we did a Workspace security review last year" and "we know our current configuration is safe right now" is exactly where most real incidents live — a Drive sharing default someone changed for convenience, an OAuth app approved during a moment of inattention, a Super Admin role granted for a project that ended eight months ago and was never revoked. Without a recurring cadence, configuration drift goes unnoticed until an attacker exploits it.

How it works

Manual Admin Console Review vs. Automated SSPM Scanning

	Manual Admin Console Review	Automated SSPM/CTEM Scanning
Setup time	None — built into every Workspace tenant	Requires connecting a third-party tool via API/OAuth
Coverage	Covers Google's own prioritized recommendations well	Covers the same plus continuous drift detection
Frequency	Point-in-time, as often as someone remembers to run it	Continuous — flags changes as they happen
Detects configuration drift	No — only reflects current state at time of review	Yes — alerts when a previously-correct setting changes
Cross-references CIS Benchmark controls	Partially, via Google's own recommendations	Typically yes, explicitly mapped
Detects newly risky OAuth grants	Only if manually reviewed each time	Often in near real time
Cost	Free (Admin time only)	Typically a paid SaaS subscription
Best for	Initial baseline assessment, smaller organizations	Ongoing posture management, regulated or larger organizations

Neither approach replaces the other entirely — a manual review is the right starting point for establishing your first baseline, while automated scanning is what actually catches the setting someone changes six months later without anyone noticing.

Step 1: Start With Google's Built-In Security Health and Security Dashboard

Navigate to Admin Console → Security → Security Health, which surfaces Google's own prioritized list of misconfigured settings with direct remediation links — this alone typically surfaces the majority of common findings without any third-party tooling. Cross-reference this against Admin Console → Security → Security Dashboard, which shows overall risk indicators including what percentage of users have 2-Step Verification enrolled — a number worth writing down as your baseline before making any changes.

Step 2: Enforce Two-Step Verification, Prioritizing Phishing-Resistant Methods

Go to Admin Console → Security → Authentication → 2-Step Verification and confirm enforcement is set to "Enforced," not merely "Allowed" or "Optional" — an unenforced 2SV policy means a leaked password alone grants full account access for any user who hasn't opted in voluntarily. For admin and executive accounts specifically, verify the second factor is a hardware security key or passkey rather than SMS, which remains vulnerable to SIM-swapping. Google's Advanced Protection Program (APP) is worth enrolling for your highest-privilege accounts specifically, since it enforces phishing-resistant security keys and blocks untrusted third-party app access by default.

Step 3: Audit Super Admin Assignment and Admin Role Sprawl

Navigate to Admin Console → Account → Admin roles → Super Admin. Every Super Admin account is a maximum-value target, and best practice caps this role at 2–3 people organization-wide — most staff performing day-to-day administrative tasks only need scoped roles like User Management or Groups Admin, not full Super Admin access. Review the full list of assigned admin roles at the same time, since role sprawl (admin permissions granted for a one-time task and never revoked) is one of the most common findings in real assessments.

Step 4: Filter for Orphaned and Inactive Accounts

Go to Directory → Users, add a filter for Last sign-in > 90 days, and cross-reference against 2-Step Verification status. Accounts that are both inactive and unprotected by 2SV represent risk with no offsetting business value — suspend them immediately, and archive or transfer any associated Drive/email data before deletion per your data retention policy.

Step 5: Lock Down Drive's Default External Sharing Settings

Navigate to Admin Console → Apps → Google Workspace → Drive and Docs → Sharing Settings. "Anyone with the link can view" is consistently the single most common Workspace misconfiguration found during assessments — it's often selected by users for convenience, without realizing the practical effect is making a file accessible to anyone on the internet who obtains the link, including through search indexing or accidental forwarding. Set the org-wide default to "Off (restricted)," and require sign-in for any file that must be shared externally. Apply the same review to per-Shared-Drive external membership settings, since defaults at the Shared Drive level can diverge from the org-wide policy.

Step 6: Review Third-Party OAuth App Access

Go to Admin Console → Security → API Controls → App Access Control, then click Review third-party access. Sort by access level and focus first on apps with Sensitive or Restricted scopes — anything with broad Gmail or Drive permissions. For each, confirm there's still a business owner and active use case; revoke access for anything unused in the past 90 days. This step specifically defends against consent phishing — a growing attack pattern where a user is tricked into approving a malicious app's OAuth request during what looks like a routine sign-in prompt, granting the app standing access to email or files without ever compromising a password.

Step 7: Confirm Email Authentication Is Set to Enforce, Not Just Monitor

Verify SPF, DKIM, and DMARC records for your domain, with DMARC specifically set to p=reject rather than p=none (monitor-only) or p=quarantine. A DMARC policy left in monitor mode collects useful reporting data but does nothing to actually stop a spoofed email claiming to be from your domain from reaching a recipient's inbox. Also enable Gmail's enhanced pre-delivery scanning under Admin Console → Apps → Gmail → Safety, which catches a meaningful share of phishing attempts that slip past default filtering.

Step 8: Configure Context-Aware Access for Sensitive Data

For organizations on plans that support it, Context-Aware Access (under Security → Access and data control → Context-Aware Access) lets you enforce conditions like requiring a current OS version, active screen lock, and disk encryption before a device can access Drive or Gmail — and can restrict access to a corporate IP range or VPN entirely for the most sensitive data. This is one of the more fiddly settings to configure correctly, but it directly addresses the growing risk of unmanaged personal devices accessing corporate data.

Step 9: Cross-Reference Findings Against the CIS Google Workspace Foundations Benchmark

The CIS Google Workspace Foundations Benchmark provides 58 controls spanning authentication, Drive, Gmail, and admin settings, and is a useful structured baseline to validate your manual findings against — particularly useful for organizations that need to demonstrate a recognized configuration standard for compliance purposes rather than an internally-defined checklist.

Step 10: Establish a Recurring Cadence, Not a One-Time Review

A single point-in-time review only reflects the state of your tenant on the day you ran it. Schedule a recurring quarterly review at minimum — monthly or continuous for regulated industries — and consider automated SaaS Security Posture Management (SSPM) tooling that flags configuration drift as it happens, rather than waiting for the next scheduled manual pass to catch a setting that changed in between.

Detection and response

Hypothesis: Your Workspace tenant has at least one high-impact misconfiguration — unenforced 2SV, permissive Drive sharing, over-privileged OAuth apps, Super Admin sprawl, or DMARC in monitor mode — that an attacker could exploit.

Evidence that confirms or rejects it:

• Security Health and Security Dashboard show Google's prioritized list of misconfigured settings and the percentage of users with 2SV enrolled.
• 2-Step Verification settings show whether enforcement is "Enforced" or merely "Allowed/Optional."
• Admin roles → Super Admin lists all Super Admin accounts; more than 2–3 indicates sprawl.
• Directory → Users filtered by Last sign-in > 90 days reveals inactive accounts; cross-reference with 2SV status.
• Drive and Docs → Sharing Settings shows the org-wide default; "Anyone with the link" is a finding.
• API Controls → App Access Control lists third-party apps with Sensitive/Restricted scopes; unused apps are a finding.
• DMARC record for your domain shows p=none (monitor) or p=reject (enforce).

What to do

1. Start with Google's built-in tools. Navigate to Admin Console → Security → Security Health and Security Dashboard to see prioritized misconfigurations and baseline 2SV enrollment.
2. Enforce 2-Step Verification. Go to Admin Console → Security → Authentication → 2-Step Verification and set enforcement to "Enforced." For admins, require hardware security keys or passkeys; enroll highest-privilege accounts in Google's Advanced Protection Program.
3. Audit Super Admin and admin roles. Navigate to Admin Console → Account → Admin roles → Super Admin and reduce Super Admins to 2–3 people. Review all assigned admin roles for sprawl.
4. Filter for orphaned accounts. Go to Directory → Users, filter for Last sign-in > 90 days, cross-reference with 2SV status, and suspend inactive unprotected accounts. Archive data per retention policy.
5. Lock down Drive sharing. Navigate to Admin Console → Apps → Google Workspace → Drive and Docs → Sharing Settings and set the org-wide default to "Off (restricted)." Require sign-in for external shares. Review Shared Drive external membership settings.
6. Review third-party OAuth apps. Go to Admin Console → Security → API Controls → App Access Control, click Review third-party access, sort by access level, and revoke apps unused in the past 90 days. Focus on Sensitive/Restricted scopes.
7. Enforce email authentication. Verify SPF, DKIM, and DMARC records; set DMARC to p=reject. Enable Gmail enhanced pre-delivery scanning under Admin Console → Apps → Gmail → Safety.
8. Configure Context-Aware Access. Under Security → Access and data control → Context-Aware Access, enforce conditions like OS version, screen lock, and disk encryption for sensitive data access.
9. Cross-reference with CIS Benchmark. Validate findings against the CIS Google Workspace Foundations Benchmark (58 controls) for compliance purposes.
10. Establish a recurring cadence. Schedule quarterly reviews at minimum (monthly or continuous for regulated industries) and consider automated SSPM tooling to flag drift.

FAQ

How long does a Google Workspace tenant scan take? A first-pass manual review using the Admin Console's Security Health and Security Dashboard pages, covering the ten steps above, typically takes 1–2 hours for a small-to-mid-sized organization; larger organizations with more complex admin role structures and Shared Drive configurations should budget more time for Steps 3 and 5 specifically.

Is Google Workspace itself insecure, or is this purely a configuration issue? Google's underlying infrastructure is generally considered highly secure and is independently certified against numerous compliance frameworks. Nearly every real-world Workspace security incident traces back to tenant-level configuration — permissive sharing defaults, unenforced MFA, over-privileged OAuth apps — not a flaw in Google's platform itself, which is exactly why a tenant scan focuses entirely on configuration rather than platform vulnerabilities.

What's the single highest-impact setting to fix first? Enforcing 2-Step Verification organization-wide, with phishing-resistant methods (security keys or passkeys) for admin accounts specifically. A leaked password with no second factor grants immediate, full account access — this single control addresses the most common initial-access vector across real incidents.

Does Google Workspace meet compliance requirements like SOC 2, HIPAA, or ISO 27001 out of the box? Google Workspace can support these frameworks, but compliance depends on your organization correctly configuring the controls each framework requires — Vault for retention, DLP rules, 2SV enforcement, audit logging — rather than being automatically compliant by virtue of using the platform. A tenant scan is a direct input into demonstrating these controls are actually in place.

Can a tenant scan be automated, or does it require manual review every time? Both a first baseline review and periodic manual spot-checks are valuable, but ongoing posture management is best handled by automated SSPM tooling that continuously monitors for configuration drift and newly granted risky OAuth scopes — a manual quarterly review alone leaves gaps for whatever changes in between review cycles.

How is a Google Workspace tenant scan different from a general cloud security assessment? A cloud security assessment (CSPM) typically covers infrastructure-as-a-service environments like AWS, Azure, or GCP — compute, storage, networking. A Workspace tenant scan is SaaS-specific, focused on identity, sharing permissions, and application access within a productivity suite rather than infrastructure configuration — though both fall under the same broader discipline of continuous configuration monitoring.

Sources

• What Is Cloud Security Posture Management (CSPM)?
• What Is Attack Surface Management (ASM)?
• What Is Zero Trust Architecture?
• Trusteed Cloud Security & Compliance
• Trusteed Blog
• Start scanning for free
• Talk to an expert

Where this fits in a program