Running a Drive security audit for one tenant is a project. Running them for forty tenants on a recurring basis is a different problem entirely. The tooling, the access model, and the reporting all change. This post is the operational guide we wish we had when we started building the MSP side of ClearVew.
Pick an access model on day one
There are three viable patterns for an MSP to access a client’s Workspace tenant. Each has tradeoffs; mixing them across clients without intent leads to operational chaos.
1. Delegated admin user
The client creates a named user in their tenant for the MSP (e.g., msp-acme@clientco.com) and grants it an admin role. The MSP authenticates as that user. Simple, audit-friendly (the user appears in the client’s admin audit log under their own identity), and supported by every Workspace tool.
Cost: one license per client tenant for the MSP user. For most MSPs that is fine on Business Standard pricing; on Enterprise it gets expensive across forty tenants.
2. MSP-owned service account with Domain-Wide Delegation
The MSP runs a single service account in its own GCP project. Each client tenant adds the service account’s OAuth client ID to their Domain-Wide Delegation list with the required scopes (typically drive.readonly for read-only audit, plus drive if remediation is in scope).
Cost: zero per-tenant license cost. Risk: the service account is a single credential that can impersonate users across every client tenant. A compromise of that key is a multi-client incident. This is why we cover key rotation specifically in the audit checklist — DWD keys are precisely the kind of credential that ages dangerously.
3. Marketplace OAuth app
The MSP publishes a Workspace Marketplace application; the client installs it domain-wide via consent flow. Permissions and scopes are visible to the client admin at install time and revocable from the Marketplace admin panel. Best UX and trust model, highest engineering investment.
Recurring scans, not one-off audits
The single biggest mindset shift between “Workspace consultant” and “MSP delivering Drive security as a service” is the move from project engagements to recurring delivery. Drive permissions decay continuously; a one-time audit is a depreciating asset the moment you deliver it.
A working cadence we see across mid-market MSPs:
- Daily delta scans. What changed in external sharing in the last 24 hours? Useful as the input to a morning triage queue.
- Weekly risk scoring.A consolidated risk score per tenant. Drives the “which clients should I call this week” conversation.
- Monthly client report. A polished PDF or web report the client sees. More on this below.
- Quarterly OAuth re-review. Connected apps with Drive scopes, per tenant. This is where shadow IT accumulates.
Client-ready reports
The hardest skill for technical MSPs to learn is that the report is the product. A great scan with a mediocre report loses business; a competent scan with a clear report keeps clients renewing. The non-negotiables:
- An executive summary the CFO can read. Three numbers max: total externally-shared files, count of high-risk findings, count remediated this period. Trend arrows.
- A risk score with a methodology footnote. Numbers without methodology are unaccountable. Pick a scoring system (we publish ours) and explain it once, in one paragraph.
- The top 10 risky files, by name.Specifics earn trust. “You have 47 high-risk files” is forgettable; “Q4 Revenue forecast.xlsx is shared with three personal Gmail addresses” is not.
- What you fixed.Without the “here is what your retainer bought you this month” section, the client question “why are we paying you?” will eventually arrive.
- What needs the client’s attention. Items requiring their decision (vendor offboarding, OU policy questions). Make the asks explicit and easy to action.
Alerting across tenants
Per-tenant alerts get noisy fast at MSP scale. The right architecture is to forward all alerts into a single MSP-side queue, tagged by client, with severity normalized across tenants. Practical patterns:
- A unified Slack or PagerDuty channel for the security team, with client name as the first token in every alert title.
- Severity normalization: a “high risk” finding for a 50-person accounting firm and a 5,000-person hospital should be ranked differently. Encode the client’s data sensitivity into the scoring.
- A per-client suppression rule for known-acceptable patterns. If a client’s Sales team always shares decks via link with expirations, suppress the alert class for that OU and trust the recurring scan to catch anomalies.
Common pitfalls
Permission scope drift
Over time, clients ask the MSP to do new things, and admin role assignments accrete. By year two the “MSP delegated admin user” in many tenants has full Super Admin. Audit your own access quarterly. The principle of least privilege applies to your own team too.
Data residency assumptions
If you scan a client’s Drive into your own MSP-side database, you are now a data processor for their content metadata. Make sure your client agreements cover this, your storage region matches client expectations, and you have a deletion process when an engagement ends. Map your practice against the NIST CSF Identify and Govern functions.
Mixing audit and remediation in the same retainer
“Find the problems” and “fix the problems” are different scopes of work. Conflating them in pricing leads to the all-too-common “why do we keep finding the same issues every month?” conversation. Either price remediation by volume, or build it into the retainer with a clear SLA on time-to-fix.
Onboarding friction
The fastest way to lose a Workspace MSP deal is a 90-minute onboarding call explaining DWD setup. Pre-build a one-page client onboarding doc with literal screenshots, invest in tooling that supports OAuth-style installs, and practice the demo until it takes 12 minutes.
Tooling fit
ClearVew was built with MSP delivery as a primary use case, not an afterthought. That means a multi-tenant dashboard, per-client risk scoring, recurring scans with delta reports, and bulk remediation that respects per-client OU boundaries. If you are evaluating us against generic Workspace audit tooling, the things to test are:
- How long does it take to add the 41st tenant?
- Can you run a single “everything that changed last week, across all clients” query?
- Does the client-facing report look like something your brand can stand behind?
- How are remediation actions audited per client, with non-repudiable records?
See the MSP Dashboard for the multi-tenant UX and pricing for the MSP-tier license model.
Closing thought
MSP-grade Workspace security is more about discipline than about cleverness. The controls themselves are the same ones in our audit checklist and the policy guide. The MSP delta is doing those things consistently, across many tenants, with a report the client wants to read, on a cadence that prevents drift. Get the operational mechanics right and the technical work mostly takes care of itself.
