The average small or mid-sized business uses between 40 and 100 SaaS applications. Most of those applications were adopted without a formal approval process. Many are connected to core business systems -- email, CRM, accounting, HR -- through integrations that no one in leadership is fully aware of.
That unmanaged application footprint is a significant source of exposure. Employees leave organizations and retain access. Applications store sensitive data under terms the business never reviewed. Integrations created for a specific project continue running long after the project ends.
SaaS governance addresses this. It is not a complex program. For most SMBs, it is a practical set of decisions and controls that bring visibility and accountability to an application landscape that has grown without either.
Before You Begin: Get Visibility
The first step in SaaS governance is knowing what you actually have. Most organizations that run this exercise discover applications they did not know were in use.
- [ ] Run a SaaS discovery process -- review browser extensions, IT help desk tickets, expense reports with SaaS subscriptions, and OAuth connections to your identity provider
- [ ] Build an application inventory that captures: application name, business owner, data categories it accesses, integration connections, and cost center
- [ ] Identify which applications are accessing sensitive data categories: client records, financial data, HR information, intellectual property
- [ ] Flag all applications with active integrations to your core systems (email, identity, CRM, file storage, accounting)
The inventory is your baseline. Governance operates against this list.
Application Approval and Onboarding
Once you have visibility, establish a consistent process for adding new applications.
- [ ] Define who can approve a new SaaS application (typically IT or a designated owner, with escalation to leadership for applications that access sensitive data)
- [ ] Establish a minimum review for all new applications: vendor security posture, data processing terms, access permissions requested, and applicable compliance considerations
- [ ] Require a business owner for every approved application -- someone accountable for its use and eventual retirement
- [ ] Document approved applications in your inventory with approval date and renewal schedule
The goal is not to slow adoption. It is to make adoption deliberate enough that the business knows what it has and what it agreed to.
Access Management
SaaS applications introduce significant access risk, particularly when employee offboarding is inconsistent.
- [ ] Verify that all SaaS applications are connected to your identity provider (SSO) where supported -- this enables centralized offboarding
- [ ] Identify applications that do not support SSO and establish a manual offboarding checklist for those
- [ ] Review admin access levels across applications -- most users do not need admin rights
- [ ] Conduct a quarterly access review: who has access to which applications, and is that access still appropriate
- [ ] Establish a formal offboarding process that includes SaaS access revocation as a required step
Access that persists after an employee departs is one of the most common and preventable SaaS exposures.
Data Handling and Vendor Risk
Not all SaaS vendors handle data responsibly. Not all terms of service reflect what you need them to.
- [ ] For applications handling sensitive data, review the vendor's security documentation: SOC 2 report, penetration test results, or equivalent
- [ ] Review data processing terms: does the vendor have the right to use your data for training AI models or other purposes you did not intend
- [ ] Identify applications storing regulated data (HIPAA, CMMC, state privacy) and confirm they meet applicable requirements
- [ ] Set a review schedule for your highest-risk vendors -- annually at minimum
This is not due diligence on every free productivity tool. It is focused scrutiny on the applications that access your most sensitive information.
Application Retirement
Applications accumulate. Governance includes a process for retiring applications that are no longer needed.
- [ ] Review your application inventory annually -- flag applications with no active business owner or demonstrable current use
- [ ] Establish a retirement process: revoke access, retrieve or delete data per vendor agreement, remove integrations, cancel subscription
- [ ] Pay particular attention to applications with active integrations -- orphaned integrations are a persistent source of exposure
A SaaS application that no longer serves a business purpose but retains access to your systems is pure risk with no offsetting value.
Ongoing Governance Responsibilities
SaaS governance is not a one-time project. These are recurring responsibilities.
- [ ] Review new application requests as they arise
- [ ] Conduct quarterly access reviews across your application inventory
- [ ] Review and update vendor risk assessments annually for high-risk applications
- [ ] Incorporate SaaS application review into employee offboarding as a standard step
- [ ] Update your inventory when new applications are approved or retired
What Good SaaS Governance Looks Like
An organization with mature SaaS governance can answer the following questions without significant effort: What applications do we use? Who owns each one? What data does each application access? Who has access? When was access last reviewed? What are our vendor security obligations for sensitive applications?
Most SMBs cannot answer those questions today. Building toward that state takes a few months of focused work -- not a multi-year program.
For organizations in the DC metro area, NightFortress advises on SaaS governance as part of AI Governance Services and the Fractional CISO Retainer. Contact us to talk through where your organization stands.