Learn
Playbook
Most articles on SaaS audits explain what to review. This one explains exactly how to do it, in what order, and what to look for at each step, so the process becomes a repeatable quarterly routine rather than a one-time project.
TL;DR
The audit has six steps executed in a fixed sequence: discovery, access mapping, spend review, permission review, remediation, and cadence-setting.
Sequence matters: skipping to spend or permissions before you have a complete app list produces an incomplete picture.
A quarterly rhythm, supplemented by event-triggered checks, is the practical operating cadence for a growing team.
ShiftControl consolidates all four audit jobs, provisioning and access, SaaS spend management, app-permission visibility, and incident response, into one platform purpose-built for Google Workspace, so a single operator can run the full sequence without an IT team.
About the Author: ShiftControl was founded by operators who personally scaled IT from 100 to over 700 employees across seven global offices at ExpressVPN. That firsthand experience of doing more with less is the lens through which this playbook is written.
Before You Start: What the Audit Covers (and Where to Learn the Why)
A complete SaaS audit touches four jobs: app discovery, access review, spend analysis, and permission assessment. The business case for each, including why shadow IT and orphaned accounts create real exposure for Google Workspace companies, is covered in depth in our SaaS management guide and the shadow IT article. This playbook assumes you have read enough to be convinced. The goal here is execution.
The Six-Step Execution Sequence
Step 1: Build a Complete App Inventory
Everything downstream depends on knowing what exists. An incomplete app list produces an incomplete audit.
Pull connected OAuth apps from the Google Workspace admin console: Admin console > Security > API controls > App access control. This gives you apps authorized through Google SSO.
That list is not the complete picture. Also collect:
Subscriptions visible in your finance system or company card statements.
Apps that employees access with standalone credentials that bypass SSO entirely.
Browser extensions with data access, which are frequently overlooked.
Organize every app into a working list with four columns: app name, how it was discovered (OAuth / finance / self-reported), the team or individual using it, and a status field you will fill in as you progress.
A dedicated shadow IT discovery tool automates this consolidation and surfaces apps that manual methods miss. If you are running the audit manually for the first time, expect the finance-and-SSO combination to surface a longer list than you anticipated.
Step 2: Map Every User to Every App
For each app on your inventory, list the accounts with active access. Then cross-reference against your current employee and contractor roster.
Flag every account that falls into one of these categories:
Flag | Description | Priority |
|---|---|---|
Departed user | Access belongs to someone no longer with the organization | Immediate revoke |
Elevated privilege | Admin or owner access that should be standard user | Verify and downgrade |
Shared credential | Generic login used by multiple people | Replace with individual accounts |
Inactive account | Account exists but shows no recent login | Confirm need or revoke |
Contractor access | External party with access beyond their engagement period | Verify and revoke |
Work through this table before moving to spend or permissions. Access mapping often reveals apps that are worth keeping but need immediate remediation, and apps that have no active users and can be cancelled outright.
Step 3: Run the Spend Review
With your app inventory and user counts in hand, you now have the context to assess spend accurately.
For each app, record: monthly or annual cost, number of licensed seats, number of seats with active users in the past 90 days, and the renewal date.
Look specifically for:
Unused seats: Licenses paid for but not actively used. These are the most common source of recoverable spend.
Duplicate tools: Two or more apps serving the same function in different teams (common examples: two project management tools, two e-signature tools, two video platforms).
Renewals within 90 days: Flag these for a decision now, before the auto-renewal clock runs out. Renewals are far easier to cancel or renegotiate before they process than after.
Apps with no active users at all: These are immediate cancellation candidates identified in Step 2 and confirmed here.
A SaaS spend management tool surfaces this automatically. Manual spreadsheet work is viable for a first audit but does not scale as your app count grows.
Step 4: Review OAuth Permissions and Data Scopes
Return to your OAuth app list from Step 1. For each connected app, review the scopes it holds. The Google Workspace admin console shows granted scopes under each app entry.
Apply this framework to every app:
Scope Level | What It Means | Action |
|---|---|---|
Read-only, narrow (e.g., view calendar) | App sees limited data relevant to its function | Acceptable if app is in active use |
Read/write, narrow | App can modify data within a specific domain | Acceptable; confirm the function requires it |
Read/write, broad (e.g., read all email, access all Drive files) | App can access most or all workspace data | Scrutinize carefully; verify vendor security posture |
Send-as or act-on-behalf-of | App can take actions as the user | Highest risk; require documented business justification |
Flag any app that holds scopes disproportionate to its stated function. An app that converts file formats does not need access to Gmail. An app that tracks meeting attendance does not need read/write access to Drive. When you cannot find a clear reason for a broad scope, that is a reason to revoke and ask questions.
Also flag apps with no publicly available security documentation or privacy policy. Vendor transparency is a basic signal.
Step 5: Remediate and Document
Work through your flagged items in priority order:
Revoke access for departed users immediately, across every app, not just core systems.
Downgrade elevated privileges to standard user access where elevation is not justified.
Remove OAuth access for apps that failed the permission review. In the Google Workspace admin console: Admin console > Security > API controls > App access control > select app > Remove access.
Cancel subscriptions for apps with no active users.
Schedule renewal decisions for apps flagged in the spend review.
For each decision, write one line of documentation: what you changed, why, and when. This creates an audit trail that becomes directly useful during any compliance review. The connection between this trail and SOC 2 readiness is covered in the SOC 2 playbook.
Keep a record of apps you reviewed and approved as well, not only the ones you changed. Positive confirmation that an app was reviewed and accepted is evidence of a functioning process.
Step 6: Set the Recurring Cadence
A single audit produces a clean baseline. A quarterly cadence keeps it current.
Schedule the full six-step sequence once per quarter. Between scheduled audits, run targeted checks when any of the following occur:
An employee or contractor departs.
A team reorganizes or an employee changes roles.
A new tool is adopted across more than one team.
A vendor announces a security incident or data breach.
The quarterly review does not need to be as thorough as the initial audit. Steps 2 and 4, access mapping and permission review, carry the most ongoing risk and deserve the most attention in routine cycles. Steps 1 and 3 are faster once the baseline inventory exists.
Running This as One Operator, Not a Team
The sequence above is designed to be owned by a single person: a COO, CTO, Chief People Officer, or founder. The tooling determines whether that ownership is practical or painful.
ShiftControl is purpose-built for Google Workspace and built for operators, not IT teams, handling all four audit jobs, provisioning and access, SaaS spend management, app-permission visibility, and incident response, from one platform. Setup takes about 10 minutes via a single Google Workspace login, with no implementation project. Cyber incident response via Blackpanda is included in the subscription, so if the audit surfaces an active exposure, you are not scrambling to find help at additional cost.
Transparent, per-user pricing is available at shiftcontrol.io, including a startup tier for early-stage teams.
Frequently Asked Questions
How long does the initial audit take?
With tooling, discovery and access mapping can be completed in a single working day. Remediation timelines depend on what you find, but the audit itself is not the multi-week project many operators expect.
Do I need SOC 2 or ISO 27001 obligations to justify running this?
No. The audit is sound operational hygiene regardless of compliance obligations. The documentation you produce in Step 5 does, however, form useful groundwork when compliance requirements arrive.
What if I find a risky app with broad OAuth scopes during Step 4?
Revoke its OAuth access via the Google Workspace admin console, notify affected users, and assess whether any data was accessed or shared unexpectedly. If the exposure appears significant, incident response coverage becomes directly relevant.
How often should the full sequence be repeated?
Quarterly for the full review. Event-triggered partial checks, covering Steps 2 and 4 at minimum, any time an employee departs, a role changes, or a new tool is adopted broadly.
References
How to Conduct a SaaS Security Audit
How to Conduct a Successful Software Audit
