How to audit your SaaS stack

why a saas audit is needed

SaaS sprawl is a natural product of growth. Every function in a growing organization solves problems by adopting the tools it needs, and the total compounds quietly over time. Many of those tools were adopted quickly, without a formal IT process, because the process was either too slow or did not exist at the time. Buying decisions are distributed now: department heads and individual contributors choose tools without an IT approval step because the work requires it and waiting feels like overhead.

The result is an environment that nobody designed. Applications process customer data without signed vendor agreements. Tools outside the identity provider escape offboarding. OAuth grants persist from applications that no longer exist as independent companies. Former employees keep active accounts in platforms IT never knew about. The problem is structural; it does not require a discipline failure. It requires a process to see and govern what is actually there, and a SaaS audit is that process.

step 1: build the inventory

The first task is building a list of every application in active use. No single source gives you this list, so you pull from several and reconcile them.

The identity provider (IdP) admin console gives the list of applications registered for SSO in Google Workspace, Microsoft Entra, or Okta. This is your governed perimeter, complete for applications that went through the IdP and blind to everything else. OAuth grants from the IdP surface applications that employees connected to your environment whether or not those applications are formally registered for SSO; the grant list often contains many more applications than the SSO list. Finance and expense data, requested as a report of recurring SaaS charges including department card statements, surfaces every subscription not in your IdP. Endpoint management data from an MDM or endpoint tool surfaces desktop applications and browser extensions not visible through the IdP. Department lead surveys, a short and direct ask about the tools each team uses daily, pays on department cards, or has connected to Google or Microsoft accounts, routinely surfaces applications that appear in none of the system sources. Reconcile all five sources into a single list, mark each application by source, and treat the gaps between sources as where the risk concentrates.

step 2: identify shadow saas

Shadow SaaS refers to applications in your environment that never went through an IT review process. They are not necessarily forbidden; they are simply unknown. Cross-reference the reconciled inventory against whatever approval or ticketing records you have. Applications that appear in the expense data, OAuth grants, or department surveys but not in IT records are shadow SaaS candidates.

For each unrecognized application, answer three questions: what data does it process, does the vendor have a Data Processing Agreement available, and is the vendor storing data in a location consistent with your GDPR and data-residency requirements. The answers determine the risk level. An application used by one employee to manage their own tasks carries different risk than one used by the sales team to store prospect and customer contact data.

step 3: review oauth grants and scopes

OAuth grants are the most common source of access that nobody is watching. When an employee connects a third-party tool to Google Workspace or Microsoft 365, that tool receives a grant specifying what it can access: mail, calendar, files, contacts, or some combination. The grant does not expire when the employee stops using the tool or leaves the company. It persists until someone revokes it explicitly.

Pull every active grant from the IdP, recording the application name, the scope granted, the user who authorized it, and whether that user's account is currently active. Three categories require immediate attention. Grants on inactive accounts can still carry live access if the application re-authenticates with a refresh token, and should be revoked immediately. High-scope grants, including full mailbox read access or full file access, warrant review against the application's actual function; a notification tool has no business reading a full mailbox, so revoke and re-authorize at a narrower scope where the vendor supports it. Grants from unrecognized applications are shadow SaaS findings to add to the inventory.

step 4: check sso and scim coverage

Single Sign-On (SSO) routes application authentication through your central identity provider. Applications inside SSO are governed centrally: close one directory account and access to all SSO-connected applications closes with it. Applications outside SSO authenticate independently and are invisible to your joiner-mover-leaver process.

From the reconciled inventory, identify which applications are inside SSO and configured (under central control), SSO-capable but not configured (a gap worth closing if the application processes sensitive data and SSO is available, often at a higher pricing tier), and outside SSO with no SSO option (needing manual access management, explicit tracking, and inclusion by name in offboarding checklists and every access review). SCIM provisioning is the next level: automated account creation, update, and deactivation via the IdP's provisioning API. Applications with SCIM active handle role changes and offboarding automatically, without a manual step in the application, and SCIM is worth prioritizing for applications that process employee, customer, or financial data.

step 5: find former-employee accounts

Offboarding through the directory closes SSO-connected access. It does not close accounts in applications that authenticate independently. 83% of employees admit they still have access to at least one account from a previous employer (Beyond Identity, 2022, self-reported). The mechanism is simple: tools adopted outside SSO hold their own user records, untouched when the directory account closes.

Pull your list of employees who left in the past 12 to 24 months. For every application that operates outside SSO or lacks SCIM provisioning, cross-reference its user list against the departed-employee list; any match is an active account that should have been closed at offboarding. For OAuth-connected applications, check grants authorized by former-employee accounts, since an active grant may still carry valid access even after the directory account is closed. The 36% of breaches that involve the use of stolen credentials (Verizon DBIR) often trace back to accounts that were not fully closed, and former-employee accounts in SaaS are one of the most common paths.

step 6: review app-to-app integrations

Beyond user OAuth grants, there is a second access layer that most audits miss: application-to-application integrations running without human involvement. A marketing automation tool synchronizing with the CRM, an HR platform sending data to payroll, a helpdesk integrated with a communication tool. Each integration holds an API key or service token that grants data access, and when the integration stops being needed the token is rarely revoked, because nobody remembers it was generated.

Check the admin consoles of your highest-risk applications, particularly those holding customer data, financial data, or employee records. Most have a section listing active API connections or installed integrations. For each integration, confirm whether it is still actively used, which application the token grants access to, and what scope that access covers. Deactivate tokens from integrations no longer in use. API keys have no expiry by default; an integration set up during a project two years ago may still hold active write access to your CRM.

step 7: review spend and duplicate tools

SaaS spend and access governance overlap more than most organizations realize. Tools bought outside standard procurement are tools whose security was never assessed, and duplicate tools for the same function mean the same data exists in multiple vendor environments with different security postures.

From finance data, identify unused or underused licenses (active user counts significantly lower than licensed seats, representing both waste and dormant accounts worth closing), duplicate tools (functions performed by more than one application, often adopted by separate teams; common examples include multiple project management tools or document signing tools, where consolidation reduces both cost and surface area), and tools purchased outside procurement (subscriptions appearing only on department card statements with no vendor review on file, treated as shadow SaaS regardless of how they were paid for).

step 8: build the vendor, dpa, and data-residency registry

The output of the inventory and review steps feeds into a maintained application registry, the foundation of everything else: access reviews, offboarding checklists, vendor assessments, and compliance documentation all depend on it. For each application, the minimum registry entry covers application name and vendor, internal owner or responsible team, primary function and data types processed, whether a Data Processing Agreement is signed and on file, data storage location (EU, non-EU, or country-specific), security certifications the vendor holds (ISO 27001, SOC 2), and whether the application is inside SSO and whether SCIM is active.

Data residency matters for GDPR compliance and increasingly for enterprise customer requirements. Applications storing EU personal data on non-EU servers require either Standard Contractual Clauses or an adequacy decision, and without the registry you cannot answer the question.

how to prioritize findings

A first audit produces a list longer than the team can address at once, so prioritization keeps the work moving. P0, address immediately: active accounts belonging to former employees in any application, OAuth grants on inactive or closed accounts, applications processing personal data with no DPA in place, and high-scope OAuth grants from unrecognized applications. P1, address this quarter: applications outside SSO that process sensitive data and have SSO available, OAuth grants with high scopes from recognized but low-priority tools, app-to-app integration tokens from integrations no longer in use, and applications with no internal owner assigned. P2, schedule for next cycle: applications with no SCIM provisioning that support it on current plans, unused license cleanup, duplicate tool consolidation, and registry entries missing secondary fields.

mapping to gdpr, nis2, and dora

A SaaS audit is a visibility project first, and the visibility it produces aligns directly with what several regulations require you to demonstrate. GDPR Article 28 requires a Data Processing Agreement with every third-party processor handling personal data, and Article 30 requires maintaining a Record of Processing Activities that includes data flows to processors; an application registry with DPA status and data types documented satisfies both. GDPR Article 32 requires appropriate technical and organizational measures, against which unrevoked OAuth grants, former-employee accounts, and applications with no access review are gaps the audit identifies. NIS2 requires in-scope organizations to manage supply chain security, including third-party services; SaaS vendors are supply chain, so vendor assessments, DPAs, and certification checks are part of a defensible posture. DORA requires financial institutions in scope to identify and manage ICT third-party dependencies, for which a SaaS application registry with vendor, data type, and criticality fields is the foundation. None of these standards require a specific tool; they require demonstrable control and documented processes, which a well-run audit produces.

common mistakes

Treating the IdP list as the full inventory shows what IT registered, not what employees actually use. Stopping at the inventory without the access review leaves the questions of who has access, whether that person still works there, and what data the application processes unanswered. Auditing OAuth grants without checking account status misses that a grant attached to a former employee's account is a P0 where the same grant from an active employee is not. Building a registry once and never updating it produces a historical document that has already drifted within weeks. Treating shadow SaaS as a discipline problem misframes the goal, which is visibility, not enforcement, since employees adopt tools because they are resourceful. And not involving finance misses the tools that finance teams discovered and department leads adopted outside any IT process; the finance reconciliation step is not optional.

how to keep it current

A full audit once a year is a reasonable baseline, but the ongoing processes matter more: reviewing OAuth grants quarterly, requiring a registry entry for every new tool, and including all non-SSO applications in offboarding checklists. The goal is a maintained inventory rather than periodic snapshots. Without a process that requires a registry entry for every new tool, the inventory falls behind within weeks.