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.

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.

---

What Is a Google Workspace Tenant Scan?

Definition: 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.

---

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.

---

How to Run a Google Workspace Tenant Scan: A Step-by-Step Guide

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.

---

Most Common Findings by Risk Category

Category	Common Finding	Typical Fix
Authentication	2SV not enforced org-wide, or admins using SMS instead of security keys	Enforce 2SV; require hardware keys/passkeys for admins
Admin roles	More than 2–3 Super Admins; unused elevated roles from past projects	Reduce to minimum necessary; audit role assignments quarterly
Drive sharing	Org-wide default set to "Anyone with the link"	Set default to "Off (restricted)"; require sign-in for external shares
OAuth apps	Unused third-party apps retaining Sensitive/Restricted scope access	Revoke apps unused 90+ days; require approval workflow for new app grants
Email authentication	DMARC set to p=none (monitoring only) instead of enforcement	Move to p=reject after confirming legitimate mail flows pass alignment
Account hygiene	Inactive accounts (90+ days) without 2SV, still enabled	Suspend inactive accounts; archive data per retention policy
Device management	"Advanced management" pushed to personal devices with no BYOD policy	Document a formal BYOD policy; scope device management appropriately

---

Frequently Asked Questions

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.

---

Related Resources

• What Is Cloud Security Posture Management (CSPM)? — the infrastructure-focused counterpart to tenant scanning
• What Is Attack Surface Management (ASM)? — extending discovery beyond a single SaaS tenant
• What Is Zero Trust Architecture? — how Context-Aware Access implements Zero Trust principles in practice
• Trusteed Cloud Security & Compliance — continuous configuration monitoring across cloud and SaaS environments

---

Don't Wait for the Next Scheduled Review

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.

Trusteed's cloud security platform extends this same continuous-monitoring discipline across your SaaS and cloud footprint, catching configuration drift the moment it happens rather than at the next quarterly review — with the same evidence-generation approach that supports SOC 2, ISO 27001, and HIPAA compliance automatically.

---

Ready to move from a one-time scan to continuous coverage? Start scanning for free or talk to an expert to see how Trusteed keeps your SaaS and cloud configuration continuously monitored, not just reviewed once a quarter.

---

This post was published on the Trusteed Blog. Trusteed provides continuous cloud and SaaS security configuration monitoring — catching misconfigurations like permissive sharing defaults, unenforced MFA, and over-privileged app access the moment they occur, with automated evidence generation for SOC 2, ISO 27001, and HIPAA.