OAuth app permissions are one of the easiest SaaS risks for small businesses to underestimate. A teammate clicks “connect Google,” “connect Microsoft,” or “sync Slack,” and a useful tool may receive long-lived access to email, files, calendars, contacts, customer records, or identity data. This checklist gives founders and lean IT teams a practical way to audit those connections without turning the company into an enterprise security program.
Why OAuth app permissions deserve a real audit
Most small businesses already run on cloud identity and SaaS: Google Workspace or Microsoft 365 for email and files, Slack or Teams for messages, HubSpot or Close for sales, Stripe for billing, Notion or ClickUp for operations, and a growing list of AI tools that promise to summarize, search, write, or automate work across those systems.
OAuth is the standard mechanism that lets one application access another service on a user’s behalf. That is useful when a calendar tool needs to read events or a CRM needs to sync contacts. It becomes risky when the team forgets which tools have access, employees approve apps without review, trial tools keep permissions after the trial ends, or broad scopes such as mailbox, drive, user directory, and admin-level access remain active long after the business need disappears.
CISA’s Secure Cloud Business Applications project was created to reduce visibility and configuration gaps in major SaaS environments such as Microsoft 365 and Google Workspace. Microsoft’s Zero Trust identity guidance also emphasizes strong authentication, ongoing risk checks, and least privilege access principles. For a small company, the translation is simple: do not let every connected app keep every permission forever.
The small-business OAuth audit checklist
Use this checklist as a lightweight operating procedure. It works whether your core identity system is Google Workspace, Microsoft Entra ID, or a smaller SaaS stack managed by a founder or operations lead.
1. Build an inventory of connected apps
Start by exporting or listing every third-party app with access to your identity, email, file storage, calendar, chat, CRM, help desk, billing, and project-management systems. Do not limit the review to “security tools.” Productivity plugins, browser extensions, AI note-takers, calendar assistants, lead enrichment tools, reporting dashboards, and automation platforms often have the most interesting permissions.
At minimum, capture the app name, vendor, owner, approver, connected platform, permission scopes, approval date, last used date if available, and whether the app has access as a user, service account, admin account, or workspace-wide integration.
2. Label the business purpose
Every connected app should have a plain-English purpose: “sync support tickets to Slack,” “send CRM call summaries,” “generate sales dashboards,” or “back up Google Drive folders.” If nobody can explain what the app does, it should move to the removal queue until someone proves it is still needed.
This step prevents the most common failure mode in small teams: keeping risky access because the app name looks familiar. A tool that was useful during a one-month test should not keep file or mailbox access six months later.
3. Review permission scopes by risk
Sort apps by the sensitivity of what they can read or change. Highest-risk access usually includes email content, cloud storage files, customer records, financial data, directory data, admin permissions, security logs, domain-wide delegation, and the ability to send messages or create automations as a user.
Google’s Workspace guidance for controlling which third-party and internal apps access Workspace data explicitly gives admins ways to review apps, manage API controls, restrict high-risk OAuth scopes, and choose settings for unconfigured apps. Microsoft Entra guidance likewise explains how admins can review and revoke permissions granted to enterprise applications.
4. Separate user-consented apps from admin-approved apps
User consent is convenient, but it can create blind spots. A salesperson might connect a prospecting tool to email. A marketer might connect a reporting tool to analytics. A founder might approve a file-search AI assistant while testing a workflow. Each individual decision can look reasonable, while the total set of permissions becomes messy.
Microsoft’s guidance on configuring user consent to applications recommends using consent settings to control when and how users can grant permissions. Small teams do not need a heavy approval board, but they do need a rule: low-risk tools can be self-approved, medium-risk tools need an owner, and high-risk scopes require admin review.
5. Remove stale and duplicate integrations
Look for apps with no owner, no recent use, duplicate functionality, abandoned trials, ex-employee ownership, or unclear value. These are the easiest wins because removing them usually does not disrupt operations.
Be especially skeptical of old AI, automation, and reporting tools. Many tools ask for broad access during onboarding because broad access reduces support friction for the vendor. That does not mean your business needs to keep every scope indefinitely.
6. Check employee departures and role changes
When a teammate leaves, most teams disable their core account. That is necessary but not always sufficient. Review apps the employee connected, automations they owned, API tokens they created, shared dashboards they maintained, and service accounts they controlled. If a departing employee owned a CRM integration, chatbot, spreadsheet automation, or AI summarization workflow, assign a new owner or shut it down.
Role changes matter too. Someone moving from finance to marketing may no longer need access to billing exports. A contractor who helped with analytics should not keep app connections into your production workspace after the project ends.
A simple risk scoring model
Small teams do not need a complex GRC platform to prioritize. Score each app from 1 to 5 across five questions, then review the highest scores first.
| Question | Higher-risk answer |
|---|---|
| What data can it access? | Email, files, customer data, billing, directory, admin logs |
| Can it change or send data? | Write, delete, send, invite, automate, or impersonate actions |
| How broad is the access? | Workspace-wide, domain-wide, all mailboxes, all files, admin consent |
| Who owns it? | No clear owner, ex-employee, contractor, or unknown trial user |
| How critical is it? | Low value, duplicate tool, abandoned pilot, or unclear workflow |
An app with broad file access, write permissions, unknown ownership, and unclear business value should be removed or re-approved. An app with narrow calendar read access, a clear owner, and an active workflow may simply need documentation and an annual review.
Special attention: AI tools connected to company data
AI tools make OAuth reviews more urgent because many of them are designed to search, summarize, classify, or automate data from multiple systems. A writing assistant that only works in a browser tab has a different risk profile from an AI agent connected to Gmail, Drive, Slack, Notion, Jira, and a CRM.
For AI integrations, ask four extra questions:
- What data can the AI system retrieve? Include files, messages, emails, calendar events, contacts, tickets, and CRM notes.
- Can it take actions? Reading is different from sending emails, creating tickets, updating CRM fields, or triggering automations.
- Is access scoped to specific folders, channels, or projects? Narrow scopes are easier to govern than workspace-wide access.
- What happens to prompts, outputs, and connected data? Review vendor documentation for data handling, retention, training, and enterprise controls before approving high-risk use.
If your team is already thinking about AI governance, connect this audit to your broader process. CyberTrendLab’s AI vendor risk assessment checklist covers vendor due diligence, while the least privilege guide for AI agents explains how to restrict tool access before agents become operational.
Recommended approval rules for a lean team
Here is a practical approval model that does not require a full security department.
- Low risk: narrow access, no sensitive data, no write permissions, clear owner. Allow with documentation.
- Medium risk: access to team calendars, non-sensitive documents, analytics, or workflow tools. Require owner approval and a review date.
- High risk: email, Drive or SharePoint-wide access, CRM, billing, customer support, admin scopes, domain-wide access, write permissions, or AI agents that can act across apps. Require admin approval, vendor review, and a removal plan.
- Prohibited by default: unknown vendor, no security documentation, no owner, consumer-only app handling sensitive business data, abandoned trial, or access requested by a departing contractor.
This model lines up with the broader Zero Trust idea: verify identity, evaluate risk, and keep access as narrow as the job allows. NIST’s digital identity guidance also treats access tokens such as OAuth tokens as mechanisms that allow an application to access services after authentication, which is why token scope, lifetime, and relying-party behavior matter.
How often should you run the audit?
For a small company, quarterly is a reasonable baseline. Run an extra review when you adopt a new AI tool, change identity providers, onboard a large group of contractors, migrate files, respond to a security incident, or complete layoffs/departures. If your team handles sensitive client data, healthcare data, regulated financial data, or enterprise customer data, monthly reviews may be more appropriate.
The audit should produce visible outcomes: apps removed, permissions reduced, owners assigned, high-risk tools approved or denied, and a dated record of what changed. A checklist that does not remove anything is not an audit; it is just an inventory.
Common mistakes to avoid
- Only reviewing paid tools. Free trials and “login with Google” tools can carry meaningful access.
- Ignoring write permissions. Read access is sensitive, but write/send/delete permissions can create operational damage.
- Trusting app names instead of scopes. A familiar brand can still request broader access than your workflow requires.
- Letting founders bypass the process. Founder-approved apps are often the riskiest because they are connected quickly during experiments.
- Failing to document removal decisions. If a tool breaks after access is revoked, you need to know who requested the change and why.
FAQ
Is OAuth itself unsafe?
No. OAuth is a standard way for apps to request delegated access. The risk comes from unmanaged approvals, overly broad scopes, stale tokens, weak ownership, and connected apps that no longer match a real business need.
Should small businesses block all user consent?
Not always. Blocking everything can slow work and push employees toward shadow IT. A better starting point is to restrict high-risk scopes, require admin review for sensitive data, and document low-risk approvals. Microsoft Entra and Google Workspace both provide admin controls for this style of review.
What should we remove first?
Remove apps with no owner, no recent use, unknown vendor status, broad file or mailbox access, admin-level permissions, or access tied to former employees and contractors. Then reduce scopes for tools that are still useful but too broadly authorized.
How does this connect to small business cybersecurity?
OAuth app reviews are part of basic identity hygiene. They complement MFA, password managers, endpoint protection, phishing training, SaaS vendor review, and secure offboarding. For a broader stack, see CyberTrendLab’s small business security stack guide and phishing prevention checklist for remote teams.
Bottom line
If your company uses cloud email, shared files, CRM, collaboration tools, and AI assistants, OAuth app permissions are now part of your attack surface. The fix is not panic or blanket bans. It is a repeatable review: inventory connected apps, rank risky scopes, assign owners, remove stale access, require approval for sensitive integrations, and repeat the process before abandoned tools become hidden exposure.
For most small businesses, the first audit will uncover more than expected. That is good news. Every stale app removed and every permission narrowed reduces risk without buying another security product.
