Configuration Review
Configuration Review of Google Workspace
Google Workspace defaults favour collaboration, which is the correct product decision and the wrong security posture for an organisation holding regulated data. Most tenants are running close to those defaults years after adoption. The review concentrates on sharing scope and third-party application access, because Drive links and OAuth grants are how data actually leaves a Workspace tenant.
Methodology
- 01
Tenant and organisational unit inventory
Domains, organisational unit structure, licensing and the settings inherited at each level, since OU inheritance is where Workspace policy usually goes wrong.
- 02
Administrative role review
Super administrator count, delegated admin roles and their scope, and whether administrators hold separate accounts from their daily identities.
- 03
Authentication review
2-Step Verification enforcement by OU, permitted methods, enrolment grace periods, and whether less secure app access or app passwords remain available anywhere.
- 04
Drive and sharing review
External sharing settings per OU, shared drive membership, link sharing defaults, and enumeration of what is actually shared outside the domain.
- 05
Gmail security review
SPF, DKIM and DMARC alignment and enforcement, attachment and link protection, routing rules, and delegation and forwarding settings.
- 06
Third-party access review
OAuth applications with domain-wide delegation, marketplace app allowlisting, and user-installed applications holding sensitive scopes.
- 07
Logging and alerting review
Audit log retention, alert centre rules, export to a SIEM where one exists, and whether anyone acts on what is produced.
- 08
Reporting and retest
Technical report and executive summary together, with changes sequenced by user impact, then a retest confirming closure.
Approach to testing
- Read-only assessment through a reviewer account holding the minimum roles required. Nothing is changed and no user is affected.
- Settings are assessed per organisational unit, not only at the root. Workspace inheritance means a root-level control can be silently overridden two levels down.
- Actual external sharing is enumerated rather than inferred from policy. A tenant that now prevents public links may hold years of links created when it did not.
- Domain-wide delegation grants are treated as privileged access, because an application with delegation can impersonate any user in the domain.
- Recommendations state user impact. Turning off external link sharing is correct and will break existing workflows, and the report says which ones.
Types of assessment
Full tenant review (default)
Every service against the CIS benchmark, assessed per organisational unit.
Identity-focused review
Administrative roles, 2SV enforcement and session controls only. The highest-value subset where scope is limited.
Data exposure review
Drive and shared drive sharing, enumerating what is actually reachable outside the domain.
Third-party access review
OAuth grants, domain-wide delegation and marketplace applications. Often run after an incident or before an audit.
Frameworks and standards
- CIS Google Workspace Foundations Benchmark
- The primary baseline, assessed control by control at the level appropriate to the client's edition.
- Google Workspace security best practices
- Google's own guidance, which is frequently ahead of the benchmark.
- NIST SP 800-53
- Control mapping where the client has a compliance obligation.
- MITRE ATT&CK for Cloud
- Technique mapping for the detection review.
- DPDP Act / GDPR
- Where the tenant holds personal data, sharing and retention settings are assessed against the applicable obligation.
Tools used
Tooling is where testing starts, not where it ends. Every automated result is reproduced by hand before it reaches a report.
GAM / GAMADV-XTD3
Read-only enumeration of settings, sharing, users and OAuth grants across the domain.
Google Admin SDK / Reports API
Programmatic export of configuration and audit data for offline analysis.
CIS-CAT or scripted benchmark checks
Automated evaluation against the Workspace benchmark.
Google Security Health dashboard
Google's own posture view, used as a cross-check rather than as the assessment.
Custom Drive enumeration scripts
Walking shared drives and My Drive for externally shared content at scale.
Checklist approach
The checklist is the floor, not the ceiling. It guarantees coverage so nothing standard is missed; the findings that matter usually come from what a tester does after it is complete.
Administrative access
- Super administrator count and separation from daily accounts
- Delegated admin roles and their scope
- 2SV enforced on all administrative accounts with security keys where available
- Administrator activity alerting
- Recovery options configured on privileged accounts
Authentication
- 2-Step Verification enforcement by organisational unit
- Permitted 2SV methods and whether SMS is still allowed
- Enrolment grace period and users still outside it
- Less secure app access and app passwords
- Session length and re-authentication for sensitive actions
- Context-aware access policies where licensed
Drive and sharing
- External sharing settings per organisational unit
- Link sharing defaults and permitted audiences
- Enumeration of files shared to anyone with the link
- Shared drive membership and external members
- Drive trust rules where licensed
- Offline access and mobile sync policy
Gmail
- SPF, DKIM and DMARC published, aligned and enforced
- Attachment, link and impersonation protection enabled
- Routing and content compliance rules reviewed for bypass
- External forwarding and delegation settings
- Confidential mode and its limitations understood
Third-party access
- Applications with domain-wide delegation and their scopes
- API access controls and marketplace allowlisting
- User-installed applications holding sensitive scopes
- Service account key age and rotation
- OAuth app verification status
Logging
- Audit log retention period
- Alert centre rules and routing
- Export to a SIEM or long-term storage
- Data export and takeout controls
How findings are scored
Every finding is scored on CVSS 3.1 and placed in one of five levels. The executive summary adds a sixth band — Compliant — so components that passed appear on the same chart as those that did not.
- Critical
- Immediate measures must be taken. These vulnerabilities can allow an attacker to take complete control of the application or server — stealing user data, tricking users into supplying sensitive information, or defacing the site.
- High
- Maximum risk associated with a specific vulnerability instance. May enable an attacker to compromise the application and its data, partially or completely, or to modify application behaviour beyond its intended purpose. To be handled with utmost priority.
- Medium
- Considerable risk. May enable an attacker to exploit the application to a particular level, gaining low-level information that can be used to craft more specific attacks.
- Low
- Lowest risk. May allow an attacker to gain some information about the application that was not intended to be known, without an exploitation technique currently available at that instance.
- Informational
- A functionality or component is missing best-practice implementation. Not a risk today, but may become one as the application changes or as exploitation techniques, policy or legal requirements evolve.
Scan types selected
- Safe Checks
- Standard / OWASP Top 10
- Destructive
- SANS Top 25
- Business Logic Vulnerability Testing
Standard toolset by stage
- OSINT
- Datasploit, Google Dorks, Shodan
- Enumeration & Scanning
- Nmap, Wfuzz, Unicornscan
- Domain Enumeration
- Nikto, DnsRecon, Knock
- Crawling & Fuzzing
- Burp Suite, Acunetix, Netsparker
- Vulnerability Analysis
- OpenSSL, sqlmap, CVE-Details
- Exploitation
- Metasploit, Netcat, Exploit-DB
How CSS tests
A unified swarm of agents, for blind spot detection
AI agents drive several testing tracks against the same target at once, then cross-check each other. A single tester works one hypothesis at a time; parallel agents cover the space a sequential pass leaves behind.
Organisational unit inheritance means the effective setting for a user depends on their position in the tree. Computing the effective policy for every user is the only way to find the OU where a control silently stops applying.
Drive sharing enumeration across millions of files is machine work. The policy setting says nothing about the historical population, which is where the exposure lives.
OAuth scope analysis across hundreds of applications and thousands of user grants surfaces the one application holding drive.readonly across the domain.
Gmail routing and compliance rules interact; evaluating their combined effect on a message is simulation rather than reading.
Every agent finding is validated by a human reviewer. The assessment is read-only throughout: no setting is changed, no user affected, nothing revoked during the review.
Why this differs
What CSS does that most vendors do not
Every one of these is checkable. Ask any vendor for the same and compare the answers.
Per-OU, not per-tenant
Most reviews report root-level settings. CSS computes the effective policy for every organisational unit, because a control overridden two levels down is a control that does not exist for those users.
What is shared, not what may be shared
The review enumerates existing external shares rather than reporting the policy governing future ones.
Both reports, always
Technical report and executive summary together, plus a change list sequenced by user impact.
Fixation, not a backlog
CSS works the change sequence with the IT team, including which changes need user communication, and retests to evidence closure.
Reporting
Two documents, two audiences
Both are produced for every engagement. They are not the same document at two lengths — they answer different questions and are written separately. The structure below is the one CSS actually issues.
Technical assessment report
For the engineers who will fix it
- Disclaimer, and Limitations on Disclosure and Use
- Risk Level & Description — the five levels above, scored on CVSS 3.1
- Scan Type — which of the five assessment types were selected
- Assessment Scope — the control areas covered
- Assessment Date — the exact testing window
- Objective of the Assessment — objectives listed against completion status
- Tools Utilization — manual and automated tooling by stage
- Summary of the Assessment
- Overall Recommendations, split into Must Have and Should Have
- Vulnerability Overall Classifications as per Organization
- Security Issues Highlighted
- The Key Findings — each with evidence and detailed recommendation
- Summary of Findings & Conclusion
For this assessment specifically
- Scope: domains, organisational units, edition and the review date
- Findings against the CIS Google Workspace Benchmark with control references
- Effective policy per organisational unit, with inheritance overrides identified
- Enumerated external sharing across Drive and shared drives
- OAuth and domain-wide delegation inventory with scopes assessed
- Prioritised change list with user impact for each change
- Retest results appended against each original finding
Executive summary
For the people who will fund the fix
- Objectives, each against a completion status
- Overall Finding of the Assessment — total threats identified, broken down by component and severity
- Summary of the Assessment
- Artefacts of the Assessment — the key findings as a numbered register with severity
- Observation of the Assessment — the major attacks the organisation should be prepared for, given what was found
- Overall Recommendation, including a Business Enabling Recommendation sequence
- Must Have and Should Have actions
For this assessment specifically
- What data can currently leave the domain, and by which routes
- Benchmark compliance as a percentage with the material gaps named
- The three changes that most reduce exposure, with user impact stated
- Regulatory position where the tenant holds personal or regulated data
- Remediation timeline and retest date
- One page
Case studies
What this finds in practice
Representative engagement patterns. Sector and scale only — no client is named, and no detail is included that could identify one.
An education group of roughly 4,000 staff and students across several organisational units.
- Finding
- 2-Step Verification was enforced at the root. A student OU created for a 2023 intake had inherited an override disabling enforcement, leaving 1,100 accounts with password-only access, several of which held delegated access to staff mailboxes.
- Recommendation
- Remove the override, enforce 2SV across every OU, and add an alert on any OU-level authentication setting change.
- Outcome
- Enforcement applied over a four-week enrolment window. The alert has since flagged one further override attempted during a support escalation.
A design agency using shared drives for client work.
- Finding
- An application installed by a single user two years earlier held domain-wide delegation with drive.readonly scope. It was a defunct productivity tool whose vendor had since been acquired, and it retained the ability to read every file in the domain.
- Recommendation
- Revoke the delegation, restrict domain-wide delegation to a reviewed allowlist, and require administrative approval for any new grant.
- Outcome
- Revoked immediately. A review of the remaining nine delegated applications found two more that were no longer in use.
A healthcare startup handling patient data under DPDP Act obligations.
- Finding
- Drive link sharing defaulted to 'anyone in the organisation with the link' and 18,000 files had been shared to 'anyone with the link', including exported datasets containing patient identifiers.
- Recommendation
- Change the default to restricted, apply Drive trust rules to prevent public links, and run a remediation pass over historical public links with a data owner review for each.
- Outcome
- Default changed the same week. The historical remediation ran over two months with data owners reviewing 18,000 files in batches; 340 were confirmed as intentionally public and re-shared through a controlled route.
Next
Scope this assessment
Most scopes are settled in one call. Tell us what the application does and who uses it, and we will tell you what testing it properly involves.