37 SaaS Subscriptions. How Many Do You Need?

You Have 37 SaaS Subscriptions. How Many Do You Actually Need?

Finance pulls the company credit-card statements.

There are two project-management platforms, three AI subscriptions, two PDF tools, several scheduling services, a webinar platform nobody recognizes, separate design accounts, file-sharing charges, and software billed to an employee who left months ago.

Someone asks:

“Why are we paying for all of this?”

IT recognizes some of it. Marketing needs several subscriptions. Sales says not to cancel one because a customer workflow depends on it. Operations suddenly remembers that another account runs an integration nobody logs into directly.

That is where SaaS gets messy.

And the number 37 in this title is only an example. It is not an industry average, benchmark, recommendation, or SimplyRem customer statistic.

One company may legitimately need 12 applications. Another may legitimately need 80.

There is no correct universal number of SaaS subscriptions.

The goal is not to reach the smallest possible subscription count. It is to understand why every application exists and make an intentional decision to Keep, Consolidate, Replace, Retire, or Investigate it.

SaaS Count and SaaS Sprawl Are Different

Your SaaS count is simply the number of Software-as-a-Service applications your organization uses.

A high number alone proves very little.

SaaS sprawl happens when applications, accounts, licenses, subscriptions, data, integrations, vendors, and identities grow faster than the organization can inventory, govern, secure, financially manage, support, and eventually retire them.

A company with 60 well-governed applications may be healthier than a business with 15 tools nobody owns.

SimplyRem's broader cloud-sprawl guidance makes the same distinction: using many services is not inherently a problem; the problem appears when purpose, ownership, access, cost, dependencies, and lifecycle status become unclear.

How SaaS Sprawl Usually Happens

Usually, nobody sets out to create a mess.

Marketing needs an e-signature tool.

Operations needs forms.

Sales needs scheduling.

Engineering needs another project system.

HR finds a useful hiring platform.

Someone experiments with an AI assistant.

A manager enters a company card, the problem gets solved, and everybody moves on.

Six months later another department solves a similar problem with a different product.

Then people leave.

Annual subscriptions renew.

Integrations keep running.

Free accounts accumulate company data.

Licenses remain assigned.

The company has not necessarily made bad decisions. It accumulated software one reasonable decision at a time.

Shadow SaaS often starts because somebody is trying to get work done.

Governance should make useful technology easier to adopt safely—not force employees into six weeks of approval for every low-risk trial.

What Is Shadow SaaS?

Shadow SaaS is software adopted outside the organization's normal IT, security, procurement, or finance visibility.

Examples include:

An employee purchasing a tool on a company card
A team creating a free collaboration account
Someone connecting Google Drive to a new AI application
A department opening its own project-management workspace
An employee installing a SaaS browser extension with company-data permissions

And remember:

“Free” is a pricing model, not a security classification.

A product can cost nothing and still hold company documents, customer information, OAuth permissions, or important workflow data.

Google Workspace, for example, provides administrators with controls for reviewing third-party applications that have accessed organizational data and the OAuth scopes those applications requested.

Start With an Inventory, Not a Cancellation List

The fastest way to create an operational problem is to look at a credit-card statement and start canceling unfamiliar software.

Before you cancel it, figure out what it actually does.

For each application, document:

Application

Business purpose

Why does the company use it?

Business owner

Which person or department can explain why it matters?

Technical owner

Who administers access, configuration, and integrations?

Billing owner

Who receives the invoice or manages the contract?

Users

Who has access?

License model

Per-seat, consumption-based, flat-rate, hybrid, or something else?

Renewal

When does the contract renew, and what is the cancellation deadline?

Data

What company information is stored there?

Integrations

What other systems depend on it?

Identity

Does it use SSO? MFA? Automated provisioning?

Exit

How would you retrieve the data, migrate workflows, and terminate access?

The FinOps Foundation's current Licensing & SaaS capability similarly emphasizes understanding licensing terms, utilization, contract structures, renewal processes, ownership, procurement, and value—not simply reducing spend.

Where Do You Find the SaaS Nobody Remembers?

No single system usually has the complete picture.

Look across:

Accounts payable
Corporate cards
Expense reports
Procurement records
Vendor contracts
Microsoft Entra enterprise applications
Google Workspace application access
SSO platforms
Password managers
OAuth grants
IT tickets
Department software lists
Email receipts
Finance systems
Employee and contractor interviews

Do this according to company policy and applicable privacy requirements. SaaS discovery is not an excuse for invasive employee monitoring.

Finance may know the vendor and charge but not the users.

IT may know the users but not the contractual commitment.

Security may understand the data risk but not whether a platform is essential to sales.

The business owner may know exactly why the application matters but have no idea who administers it.

The inventory becomes useful when those views come together.

Every Important SaaS Tool Needs Ownership

Do not automatically make IT the business owner of every application.

The business owner should be able to answer:

Why do we use this?
Which workflow depends on it?
Who needs it?
Is it still worth paying for?

The technical or administrative owner may be someone else.

That person should know:

Who can administer the platform
How users are provisioned
How users are removed
How SSO or MFA is configured
Where important settings live
Which integrations depend on it

Billing ownership matters too.

Record the cost center, contract owner, payment model, renewal date, and notice period.

Do not place card numbers, passwords, API keys, or other sensitive credentials in ordinary SaaS inventory documentation.

Find Unused Licenses—Carefully

A terminated employee still holding a paid seat is worth reviewing.

So is a duplicate account or premium license assigned to someone who only needs basic features.

But this is where a quick cost-cutting exercise can create a bigger operational problem.

Unused and unnecessary are not always the same thing.

A low-activity license might belong to:

A seasonal employee
An emergency administrator
An occasional specialist
A compliance-related function
An automated process
A shared operational resource

Do not rely only on Last Login.

Meaningful usage depends on the product.

For one application it may mean documents created.

For another:

Reports viewed
Tickets handled
Projects updated
Meetings hosted
Workflows executed
API activity
Storage usage
Active days

The FinOps Foundation distinguishes provisioned or assigned licensing from meaningful activity and encourages organizations to evaluate usage in context rather than treating one utilization measure as the whole answer.

Right-Size Before You Cancel

Sometimes an employee needs the application but not its most expensive plan.

Perhaps the platform offers basic, standard, and premium tiers.

A handful of employees may genuinely depend on premium capabilities. Everyone else may not.

That is license rightsizing: matching licensing level and quantity to actual business requirements.

Contract terms matter.

You might identify 40 seats that are no longer operationally needed but still be committed to a 100-seat contract until renewal.

Those are two different things:

Operational Opportunity

You no longer need the seats.

Immediate Financial Savings

Your contract determines what can actually change today.

Microsoft's current FinOps licensing guidance likewise recommends reviewing procurement, deployment, utilization, compliance, and ongoing subscription usage rather than treating licenses as a one-time purchase decision.

Duplicate Tools Are Where People Get Overconfident

The company discovers three project-management tools.

Easy. Keep one, cancel two.

Not so fast.

Two tools doing similar things isn't automatically waste.

Marketing may use one for external client approvals.

Engineering may use another because it connects tightly to development workflows.

Operations may use a third for field coordination.

Could they consolidate? Maybe.

Should they? You need evidence.

Duplicate SaaS becomes more suspicious when:

The same team uses both for the same work
Features overlap heavily
Employees are unsure which system is authoritative
Data is duplicated
One tool receives almost no meaningful use
Both renew automatically without review

But duplicate tools may be legitimate because of:

Different customer requirements
Specialized functionality
Separate departments
Security boundaries
Migration periods
Acquisitions
Business-continuity requirements

Consolidation is a business decision—not a scavenger hunt for duplicate logos.

Define the System of Record

A system of record is the authoritative source for a particular kind of business information.

Maybe your CRM owns customer relationship information.

The HR system owns employee records.

Accounting owns financial transactions.

A project platform owns active project tasks.

Several SaaS systems can coexist successfully when everyone understands which one is authoritative.

Problems begin when the same customer address, project status, contract, or employee information exists in three places and nobody knows which version should win.

Subscription cost is only one part of SaaS sprawl.

Duplicate data creates operational cost too.

Do Not Forget the Administrative Cost

Every application can introduce work around:

User onboarding
Offboarding
MFA
SSO
Support
Security review
Vendor review
Billing
Renewals
Data retention
Integrations
Documentation

The problem usually isn't one $30 subscription.

The problem is dozens of local decisions creating a portfolio that nobody can confidently operate.

Check Integrations Before Canceling Anything

This is one of the most important checks in a SaaS review.

An application may appear unused because employees rarely open it.

Meanwhile it may:

Receive webhooks
Run automations
Send customer notifications
Provide API access
Feed reports
Synchronize data
Store integration credentials
Move files between systems

The user may never log in because the integration is the user.

Document the API, authentication method, connected systems, business workflow, and integration owner.

SimplyRem's current API guidance describes APIs as a way for business systems to exchange information and automate otherwise manual workflows, which is exactly why integration dependencies need to be mapped before retirement.

AI SaaS Deserves Its Own Review

AI subscriptions can accumulate quickly because the buying decision is often individual.

Employees may independently use:

General chat assistants
Coding assistants
Meeting-note tools
AI search
Writing assistants
Image-generation services
AI sales platforms
Specialized industry AI

Do not simply ask which AI is “best.”

Ask:

What business problem does it solve?
Does another approved product already provide that capability?
What company data can it access?
Does it support organizational administration?
Is SSO available and appropriate?
Who owns the account?
Are departed users removed?
Which provider and model process the data?
What are the current retention and training policies?
Which integrations are connected?

Different AI providers have different data-handling models. Verify current provider terms before making tool-specific decisions.

Trials Need Owners Too

A free trial should have:

A purpose
An owner
Intended test users
An expiration date
A review decision

Otherwise a two-week experiment can quietly become an annual contract.

A renewal date should not be the first time anyone asks whether the tool still matters.

Former Employees Are a SaaS Problem Too

Offboarding cannot stop after disabling Microsoft 365 or Google Workspace.

Review whether the employee also had:

Direct SaaS accounts
Admin roles
Licensed seats
OAuth grants
API tokens
Shared-workspace membership
Vendor portals
Automation ownership

Also transfer business assets before deleting accounts where necessary:

Documents
Dashboards
Automations
Reports
Forms
Projects
Calendars
Integrations

Microsoft Entra's current application-provisioning documentation explains that compatible provisioning systems can automate account creation, maintenance, and deprovisioning, including through SCIM.

That is useful—but not every SaaS product supports automated provisioning.

SSO, MFA, and SCIM

SSO, or single sign-on, allows users to authenticate through a centralized identity system.

That can improve visibility and make access removal easier.

But not every low-risk SaaS application needs the same identity architecture.

Use a risk-based approach.

MFA, or multi-factor authentication, adds another authentication factor beyond a password. Important business applications should be reviewed for available MFA controls, administrator protection, and account-recovery practices.

SCIM, or System for Cross-domain Identity Management, is a standard used by compatible identity platforms and SaaS applications to automate user and group provisioning and deprovisioning.

SSO does not magically make every application secure, and SCIM support is not universal.

SaaS Inventory Is Also a Security Inventory

NIST CSF 2.0 frames cybersecurity around organization-wide risk-management outcomes, while NIST's supply-chain guidance recommends maintaining supplier visibility and applying requirements proportionally to supplier criticality and data sensitivity.

That is why SaaS inventory is not merely an accounting project.

It affects:

Security
Identity
Data governance
Supplier risk
Business continuity

CISA's Secure Cloud Business Applications project similarly provides SaaS-focused configuration and visibility guidance for platforms such as Microsoft 365 and Google Workspace.

For each important application ask:

What data does it hold?
Who has administrative access?
Does it support MFA?
Does it use SSO?
What integrations have access?
Are useful logs available?
Can the data be exported?
How would accounts be deleted?

Keep the depth proportional to risk.

Do not spend the same review effort on a low-risk $20 utility that you would spend on a platform holding customer financial information.

OAuth Connections Count Even When the Subscription Does Not

An employee can connect an application to Google Workspace, Microsoft 365, Slack, Salesforce, or another platform without creating a large recurring charge.

The integration may retain access after the employee stops actively using the app.

Google Workspace administrators can review accessed third-party applications and requested OAuth scopes from the Admin console.

So SaaS cleanup should include connected applications, not only invoices.

Cancellation Is Often a Small Migration Project

Before canceling an important SaaS application, ask what company data lives there.

You may need:

Documents
Records
Contacts
Reports
Configuration
Audit information
Attachments
Metadata

And test the export.

A CSV containing basic rows does not necessarily preserve attachments, relationships, workflow history, permissions, or application-specific context.

For an important SaaS platform, cancellation is often a small migration project—not just a billing action.

Consider:

Users
Data
Integrations
Training
Workflow changes
Retention
Replacement systems
Access removal
Contract commitments

Manage Renewals Before They Happen

Do not wait for:

“Your subscription renewed successfully.”

Track contractual decision deadlines.

Annual

Potential benefit:

Lower negotiated price
More predictable budgeting

Tradeoff:

Longer commitment

Monthly

Potential benefit:

Flexibility

Tradeoff:

May have a higher unit price

Neither is automatically better.

A multi-year commitment deserves even more review around adoption, expected company growth, minimum seat counts, product direction, vendor risk, and exit flexibility.

Do not sign a long contract only because the discount looks attractive.

Not Every SaaS Product Charges Per Seat

Seat-based SaaS

Cost is primarily tied to licensed users.

Review assigned seats, meaningful use, tier level, duplicate users, and terminated accounts.

Consumption-based SaaS

Cost changes with activity such as API calls, AI usage, communications, storage, or data processing.

Review consumption, unit economics, thresholds, overages, and forecasts.

Hybrid SaaS

Some products combine a base subscription, seats, usage charges, and add-ons.

Do not evaluate the headline seat price alone.

Bigger Spend Does Not Automatically Mean Bigger Waste

A $100,000 platform running a mission-critical revenue workflow may deliver substantially more business value than ten inexpensive tools nobody understands.

Likewise, not every utility needs a clean revenue ROI calculation.

Password management, backup, identity, and security tools may create value through operational capability and risk reduction.

FinOps is not simply a mandate to cut every bill.

It is a collaborative discipline for understanding technology cost, usage, accountability, and business value.

Five Decisions for Every SaaS Application

Keep

Keep the application when it has:

Clear purpose
Appropriate usage
Acceptable security
Needed integrations
Reasonable cost
No clearly better existing substitute

Consolidate

Consider consolidation when several tools perform substantially overlapping work and users can move without damaging important workflows.

Do not consolidate only to reduce the app count.

Replace

Consider replacement when the existing product no longer fits requirements, security or support concerns exist, cost no longer makes sense, or another solution provides materially better business fit.

Retire

Retire when the tool is no longer needed, dependencies have been resolved, required data is preserved, users have moved, and contractual terms allow cancellation.

Investigate

Use this when:

Nobody knows why it exists
Usage is unclear
Ownership is unknown
An integration may depend on it
Cancellation risk is uncertain

“Investigate” is a valid decision. You do not need to cancel something just because the first meeting did not produce an answer.

Ask: “What Breaks If We Turn It Off?”

Before cancellation ask:

If this application stopped working tomorrow, who would call IT first and what would they be unable to do?

If three departments immediately identify important processes, it probably isn't unused.

If nobody cares, it may be a retirement candidate.

If nobody knows, investigate.

Unknown does not mean unnecessary.

Unknown means research required.

Microsoft 365 and Google Workspace

Some businesses intentionally operate both.

Reasons might include:

Acquisition
Migration
Different divisions
Customer requirements

Running both without a clear operating model can also create duplicate licensing, file-sharing confusion, collaboration fragmentation, and more complex identity administration.

SimplyRem's current collaboration practice supports both Microsoft 365 and Google Workspace, including tenant administration, SSO, provisioning, governance, migration, and related identity work.

The right answer is not automatically “pick one.”

First understand why both exist.

Slack and Teams

Same rule.

Do not begin with:

“One has to go.”

Review:

User groups
External collaboration
Integrations
Workflow differences
Licensing
Microsoft 365 entitlements
Company communication habits

Duplicate category does not automatically mean duplicate value.

File Storage Sprawl

A company might have combinations of SharePoint, OneDrive, Google Drive, Dropbox, Box, and other repositories.

Ask:

Which platform is authoritative?
Where should employees save company files?
Which customers require another platform?
Are permissions governed consistently?
Is the same information copied everywhere?

Knowledge sprawl creates similar problems across SharePoint, Drive, Notion, Confluence, Slack, Teams, and project systems.

SimplyRem's current internal-communication guidance emphasizes defining where information belongs and which system should be authoritative rather than simply adding more collaboration tools.

Procurement Should Be Fast Enough That People Use It

Bad policy:

“Nobody can try any new software.”

That pushes useful experimentation outside the process.

A more practical model is proportional.

Low-Risk Trial

Fast, lightweight review.

Normal Business SaaS

Review:

Owner
Purpose
Billing
Users
Data
Access
Renewal

Sensitive or Business-Critical Platform

Add deeper:

Security
Privacy
Architecture
Procurement
Legal review where appropriate
Vendor-risk review

NIST's supply-chain guidance similarly supports scaling supplier requirements according to criticality and potential impact.

SaaS Governance Is a Team Sport

Finance sees spend.

IT sees applications and accounts.

Security sees data and access risk.

Procurement sees contracts.

The business sees value.

Legal or privacy teams may become relevant for sensitive services.

That does not mean seven people should approve every inexpensive utility.

Scale governance to the risk and dependency.

Small Businesses Can Start Simple

A 20-person company may not need another expensive SaaS-management platform just to manage SaaS.

A practical starting point may be:

Central application inventory
Named owners
Renewal calendar
Basic finance reconciliation
IT/security review
Offboarding checklist

And yes, a spreadsheet can be perfectly reasonable at smaller scale.

The spreadsheet becomes a problem when nobody maintains it, information goes stale, access is uncontrolled, or the environment outgrows manual tracking.

Use tools appropriate to your scale.

SaaS FinOps

FinOps for SaaS applies collaborative financial-management practices to software subscriptions and SaaS consumption.

It can involve:

Visibility
Ownership
Usage
Forecasting
Procurement
Optimization
Renewal management
Cost allocation
Business value

The current FinOps Framework specifically treats SaaS as a technology category requiring coordination among finance, procurement, ITAM/SAM, security, product, engineering, and business stakeholders.

Again:

FinOps is not simply a mandate to cut every bill.

Useful SaaS Metrics

Track metrics that help people make decisions.

Total SaaS Spend

Useful for financial visibility.

Not enough by itself.

Cost by Department

Useful for accountability and planning.

Purchased Licenses

How many seats did the company buy?

Assigned Licenses

How many have been provisioned?

Meaningfully Active Licenses

How many are actually supporting relevant use?

Underused Licenses

Candidates for investigation—not automatic deletion.

Upcoming Renewals

Makes contract decisions visible before they become automatic commitments.

Applications Without Owners

A governance warning.

Former Users With Access

An identity-lifecycle concern.

Do not turn an arbitrary utilization percentage into a company-wide rule.

Do Not Optimize From a Dashboard Alone

A dashboard may say:

14 inactive licenses.

Useful.

Now investigate.

Check:

Seasonal use
Integration activity
Administrative use
Business owner
Contract minimums
Upcoming projects

Automation should assist SaaS decisions, not replace business context.

Application Rationalization

Application rationalization is a structured review of the application portfolio to decide what should be kept, consolidated, replaced, retired, or investigated.

It does not mean “fire the software.”

It means making the portfolio intentional.

Business Critical, Important, Convenient, or Unknown

Business-Critical

If unavailable, a meaningful business process stops.

Important

The business can continue, but work becomes materially harder.

Convenient

Useful, but realistic alternatives exist.

Unknown

Nobody currently understands the dependency.

This is an illustrative classification, not an official security rating.

Most importantly:

Do not cancel Unknown first.

Investigate it first.

SaaS Retirement Process

For a meaningful application:

Confirm business-owner approval.
Review contract and cancellation terms.
Identify all users.
Identify admins.
Identify API and automation dependencies.
Identify stored data.
Review retention requirements.
Export or migrate required information.
Move workflows.
Disable integrations.
Remove user access.
Cancel according to contract.
Verify expected billing termination.
Revoke relevant OAuth or API access.
Update documentation.
Monitor for missed dependencies.

SaaS Consolidation Process

Suppose the company has three file-sharing services.

Discover

Who uses each?

↓

Understand

Why?

↓

Review Actual Workflows

Do not compare marketing feature lists alone.

↓

Define the Target State

Maybe one platform remains.

Maybe two.

Maybe all three still have justified roles.

↓

Migrate Required Data

↓

Update Integrations

↓

Communicate and Train

↓

Retire Old Systems Safely

↓

Verify Billing

A Practical SaaS Review

Gather finance and expense information.
Gather identity and IT application information.
Interview departments.
Build the initial SaaS inventory.
Identify business owners.
Identify billing owners.
Identify administrators.
Identify users and licenses.
Determine meaningful usage.
Identify stored company data.
Map integrations.
Review identity and security.
Identify overlapping capabilities.
Review contracts and renewals.
Classify business criticality.
Decide Keep / Consolidate / Replace / Retire / Investigate.
Build migration or retirement plans.
Right-size licenses where appropriate.
Document ownership and renewal information.
Establish ongoing governance.

An Illustrative 30-Day Starting Framework

This is a starting framework—not a promise that every SaaS cleanup can be completed in 30 days.

Week 1 — Discover

Find subscriptions, applications, owners, departments, and spend.

Week 2 — Understand

Review users, usage, data, integrations, contracts, and security.

Week 3 — Decide

Classify applications as:

Keep.

Consolidate.

Replace.

Retire.

Investigate.

Week 4 — Act Carefully

Remove obvious unnecessary seats where permitted, plan migrations, document renewals, and improve procurement and offboarding.

Large environments or critical migrations can take considerably longer.

So How Many SaaS Subscriptions Do You Actually Need?

As many as the business can justify and responsibly manage—and no more.

For every application ask:

Does it solve a real problem?
Does somebody own it?
Does somebody meaningfully use it?
Does it fit our security requirements?
Does it fit our workflow?
Does its cost make sense?
Do we know when it renews?
Do we know how to leave?

If yes, keeping it may be the correct decision.

If not, investigate.

The right number of SaaS subscriptions is not 10, 20, 37, or 50.

It is the number your company can justify, secure, support, and intentionally manage.

SaaS-Sprawl Definition Card

SaaS Sprawl

Definition

SaaS sprawl is the uncontrolled or insufficiently governed growth of applications, licenses, accounts, subscriptions, data, integrations, identities, and vendors.

Important distinction

A large SaaS portfolio is not automatically sprawl.

Warning signs

Purpose is unclear
Ownership is unclear
Cost is unclear
Access is unclear
Risk is unclear
Retirement path is unclear

Shadow-SaaS Card

Shadow SaaS

Definition

SaaS adopted outside normal IT, procurement, security, or finance visibility.

Examples

Employee-paid business application
Free team workspace
Unreviewed AI platform
SaaS connected to company data through OAuth
Department-created software account

Remember

“Free” is a pricing model, not a security classification.

SaaS Inventory Card

Application Name

Purpose: Why does it exist?

Business Owner: Who needs the capability?

Technical Owner: Who administers it?

Billing Owner: Who manages the expense or contract?

Users: Who has access?

Licensing: Seat, consumption, flat-rate, or hybrid?

Renewal: When and under what terms?

Data: What company information is stored?

Integrations: What depends on it?

Identity: SSO/MFA/provisioning status.

Exit: How would the company leave?

SaaS Discovery Checklist

Search:

Accounts payable
Corporate credit cards
Expense reports
Contracts
Procurement records
Microsoft Entra
Google Workspace
SSO providers
Password managers
OAuth grants
IT tickets
Department interviews
Finance systems
Email receipts
Vendor portals

Application Ownership Card

Business Owner

Should be able to answer:

Why do we need it?
Who uses it?
Which business workflow depends on it?
Is the application still valuable?

Technical Owner

Should understand:

Administration
Access
SSO/MFA
Provisioning
Integrations
User removal
Support paths

These roles may be different people.

Billing Ownership Card

Document:

Billing owner
Cost center
Monthly/annual/multi-year commitment
Renewal date
Cancellation notice requirement
Contract owner
Current license quantity

Do not store card details, passwords, tokens, or sensitive credentials in general inventory documentation.

Meaningful-Usage Card

Do Not Measure Only Logins

Meaningful usage may include:

Active days
Documents created
Projects updated
Tickets resolved
Reports viewed
Meetings hosted
API calls
Automations executed
Storage used

The right measure depends on what the application does.

Unused-License Card

Possible Review Candidate

Former employee
Duplicate account
No meaningful activity
Feature never used

Before Removing It

Check:

Seasonal use
Administrative use
Automation
Integration dependency
Compliance purpose
Contract requirement

Unused and unnecessary are not always the same thing.

License-Rightsizing Card

Rightsizing

Match license quantity and tier to actual requirements.

Possible actions:

Remove clearly unnecessary seats
Move some users to lower tiers
Retain premium capabilities for users who need them
Adjust quantity at renewal when contractual terms allow

Do not assume the cheapest license is automatically appropriate.

Duplicate-Tool Card

Duplicate Category Does Not Equal Duplicate Value

Investigate:

User groups
Actual workflows
Integrations
Customer requirements
Specialized features
Data ownership
Migration status
Security boundaries

Decision

Consolidate only when the business case supports it.

System-of-Record Card

System of Record

The authoritative system for a category of business information.

Examples:

CRM: customer relationship data

HRIS: employee records

Accounting: financial transactions

Project system: work status and tasks

Clear systems of record reduce conflicting copies and reporting ambiguity.

Integration-Dependency Card

Before retiring SaaS, check whether it:

Receives webhooks
Runs automation
Provides API access
Sends notifications
Synchronizes records
Stores credentials
Feeds reports
Supports customer workflows

Remember: The user may never log in because the integration is the user.

AI-SaaS-Sprawl Card

Review:

Business need
Owner
Users
Overlapping AI capability
Data access
Authentication
Administration
Provider/model
Retention policy
Training/data-use policy
Integrations
Cost

Do not assume every AI service handles company information the same way.

Trial-Subscription Card

Every trial should have:

Problem being tested
Owner
Trial users
Allowed data
Expiration date
Evaluation criteria
Purchase/Reject/Extend decision
Cleanup process if rejected

Former-Employee SaaS Card

Check for:

Direct SaaS accounts
Licensed seats
Administrator roles
OAuth access
API tokens
Shared workspaces
Automation ownership
Business documents
Dashboards
Reports
Integrations

Disabling the primary identity account does not necessarily remove every independent SaaS account.

SSO Card

Single Sign-On

SSO centralizes authentication through an identity provider.

Potential benefits:

Centralized identity
Easier access removal
Better visibility
Integration with MFA

Not every SaaS product requires or supports SSO.

Apply requirements according to business and data risk.

SCIM Card

SCIM

SCIM stands for System for Cross-domain Identity Management.

Compatible identity and SaaS platforms can use SCIM to automate:

User creation
User updates
Group membership
Deprovisioning

SCIM can reduce manual lifecycle mistakes but is not supported by every application.

SaaS-Security Review Card

For important applications review:

Data stored
Authentication
MFA
SSO
Admin accounts
Integrations
OAuth access
Logs
User lifecycle
Export capability
Account deletion
Recovery
Vendor criticality

Review depth should be proportional to risk.

Data-Export Card

Before cancellation determine:

What needs export

Documents
Contacts
Records
Reports
Audit information
Attachments
Configuration

Verify

Format
Completeness
Metadata
Relationships
Attachments

A CSV does not necessarily preserve the full application.

SaaS-Retirement Card

Before retirement:

Owner approves
Contract checked
Users identified
Integrations mapped
Data reviewed
Retention addressed
Export tested
Replacement ready
Access removed
OAuth/API connections revoked
Billing verified
Documentation updated

Possible benefit

Lower negotiated pricing and predictable budget.

Tradeoff

Longer commitment.

Monthly

Possible benefit

Greater flexibility.

Tradeoff

May carry a higher unit cost.

Neither structure is universally better.

Seat-Based SaaS Card

Review:

Purchased seats
Assigned seats
Active users
Actual need
License tier
Former users
Duplicate accounts
Contract minimums

Consumption-Based SaaS Card

Examples can include:

APIs
AI
Communications
Storage
Data platforms

Review:

Consumption
Unit price
Forecast
Limits
Overage terms
Unnecessary activity
Business outcome

FinOps-for-SaaS Card

SaaS FinOps

A collaborative approach to understanding and managing SaaS cost, consumption, contracts, and value.

Common areas:

Visibility
Ownership
Procurement
Usage
Forecasting
Optimization
Renewals
Accountability

FinOps is not simply cost cutting.

Keep Card

Keep

Appropriate when:

Business purpose is clear
Usage is appropriate
Cost is justified
Security is acceptable
Dependencies are understood
No better existing substitute exists

Consolidate Card

Consolidate

Consider when:

Several products perform substantially overlapping work
Actual workflows can move
Migration is practical
Users can be supported
Data and integrations can be transferred

Do not consolidate solely to decrease the application count.

Replace Card

Replace

Consider when:

Requirements changed
Security concerns remain unresolved
Support is poor
Cost no longer makes sense
UX is damaging the workflow
Another platform is a materially better fit

Retire Card

Retire

Appropriate when:

No valid need remains
Dependencies are resolved
Required data is preserved
Users have migrated
Contract terms allow cancellation
Access and integrations can be closed safely

Investigate Card

Investigate

Use when:

Owner unknown
Purpose unclear
Usage unclear
Integration dependency possible
Cancellation consequences unknown

Unknown is not the same as unnecessary.

“What Breaks If We Turn It Off?” Checklist

Ask:

Which employees notice first?
Which customer process stops?
Which integration fails?
Which reports stop updating?
Which data becomes inaccessible?
Which automation disappears?
Which department calls IT?
Is there a manual fallback?
Can the tool be restored quickly?

Microsoft 365 and Google Workspace Overlap

Some organizations legitimately run both because of acquisitions, migrations, separate business units, or customer requirements.

Potential unmanaged overlap can involve:

Email
File storage
Meetings
Calendars
Identity
Collaboration
Licensing

Do not consolidate until the reason for coexistence is understood.

Slack and Teams Overlap

Do not start with:

“One must go.”

Review:

Users
Customer/external collaboration
Integrations
Workflow
Microsoft licensing
Existing historical knowledge
Communication patterns

Sometimes consolidation makes sense.

Sometimes keeping both does.

Multiple File-Storage Platforms

If SharePoint, OneDrive, Google Drive, Dropbox, Box, or other services coexist, ask:

Which is authoritative?
Where should employees save files?
Which external parties require another platform?
Is data duplicated?
Are sharing permissions governed?
Does each system have an owner?

Multiple AI Tools

Employees may use multiple:

Chat assistants
Coding assistants
Meeting AI
Search AI
Writing tools
Image-generation tools
Specialized AI applications

Review the business use, overlap, administration, data handling, identity, retention, integrations, and actual user need before consolidating.

SaaS-Procurement Checklist

Before purchase:

What problem does it solve?
Do we already own that capability?
Who owns the requirement?
Who will use it?
What data will enter it?
What identity/security controls are required?
What integrations are needed?
What happens after the trial?
What are the contract terms?
Can data be exported?
How do we cancel?
When will value be reviewed?

SaaS-Renewal Checklist

Review:

Current business purpose
Owner
Users
Meaningful usage
License tiers
Duplicate capability
Security
Integrations
Data
Contract minimums
Cancellation terms
Alternatives
Business-owner approval

Offboarding Checklist

Remove or review:

Primary identity
SSO access
Direct SaaS accounts
Admin roles
API tokens
OAuth grants
Shared workspaces
Licensed seats
Automation ownership
Documents and dashboards
Forms and reports
Integration ownership

SaaS-Documentation Card

For critical applications document:

Purpose
Business owner
Technical owner
Billing owner
Administrators
Users
Renewal
Data
Integrations
Identity
Support contact
Exit procedure

Do not document raw passwords or API secrets in ordinary records.

SaaS Metrics Cards

Total SaaS Spend

Measures overall financial exposure.

Spend by Department

Supports visibility and accountability.

Purchased Licenses

Seats contractually available.

Assigned Licenses

Seats provisioned.

Meaningfully Active Licenses

SaaS Trial Process

Define the problem.
Assign an owner.
Choose trial users.
Avoid unnecessary sensitive data.
Record the expiration date.
Measure actual usefulness.
Approve, reject, or extend intentionally.
Remove data and access if rejected.

SaaS Retirement Process

Confirm owner approval.
Review contract.
Identify users.
Identify admins.
Identify integrations.
Identify stored data.
Review retention.
Export required information.
Migrate workflows.
Disable integrations.
Remove access.
Cancel according to contract.
Verify billing.
Revoke OAuth/API access where appropriate.
Update documentation.
Monitor for missed dependencies.

SaaS Consolidation Process

Discover

Who uses each platform?

↓

Understand

Why?

↓

Compare Real Workflows

Not vendor feature lists.

↓

Choose Target State

One, two, or several tools may remain.

30-Day Illustrative Cleanup Framework

This is an illustrative starting framework—not a universal project schedule.

Week 1 — Discover

Applications
Spend
Owners
Departments
Contracts

Week 2 — Understand

Users
Usage
Data
Integrations
Security
Renewals

Week 3 — Decide

Keep
Consolidate
Replace
Retire
Investigate

Week 4 — Act Carefully

Reclaim clearly unnecessary seats
Plan migrations
Document renewals
Improve offboarding
Improve procurement

Critical migrations may take substantially longer.

Quarterly SaaS Review Checklist

Depending on risk and organizational needs, periodically review:

New applications
Application owners
User counts
Former employees
Inactive accounts
License levels
Contract changes
Upcoming renewals
Duplicate capabilities
Security changes
Integration changes
New OAuth applications

Quarterly is a useful example cadence, not a universal compliance requirement.

Annual SaaS Strategy Checklist

Ask:

Is this still the right platform?
Has our business process changed?
Does another product now cover this capability?
Are we using the correct license tier?
Are users actually benefiting?
Is vendor risk still acceptable?
Is the contract structure appropriate?
Can the data be exported?
Are dependencies documented?
Is there a realistic exit path?

Healthy / Caution / High Risk SaaS Cards

Healthy

Complete inventory
Named owners
Renewals known
Users periodically reviewed
Former users removed
Identity controls based on risk
Licensing understood
Integrations documented
Exit paths known
Duplicate tools intentional

Caution

Some department purchases missing
Several unexplained overlapping applications
License usage unclear
Renewals reviewed late
Access reviews inconsistent
Company tools owned through individual employee accounts

High Risk

No complete inventory
Former employees remain admins
Critical SaaS has no backup administrator
Important data resides in unknown platforms
Renewals occur without owners
Undocumented APIs depend on individual accounts
No data-export path
Shared credentials are broadly used

This is an illustrative management framework, not a formal security assessment.

SaaS Decision Path

Do we know why the application exists?

No → Investigate.

Keep intentionally.

Common SaaS-Management Mistakes

Cancel Based Only on Last Login

An integration, seasonal user, or security function may still depend on the account.

Consolidate Based Only on Feature Lists

Two products saying “project management” does not mean they support the same workflow.

Let Every Department Buy Software With No Visibility

Decentralized purchasing without discovery creates ownership, security, and renewal problems.

Make Procurement So Slow Employees Work Around It

Governance should reduce risk without blocking ordinary work.

Forget Free SaaS

Free applications may still contain company information.

Forget AI Tools

AI subscriptions and data connections can proliferate quickly.

Forget API Integrations

An apparently inactive application may automate critical work.

Disable the Employee but Leave SaaS Access

Primary-directory offboarding may not cover independent accounts.

Allow Renewals With No Owner

A recurring charge should not substitute for a business decision.

Export a CSV and Assume Migration Is Complete

Attachments, relationships, configuration, and history may be missing.

Evaluate Security Tools Only by Login Frequency

Some security tools provide value continuously without frequent human logins.

Track Cost but Ignore Data

A free platform holding sensitive information may be more important to review than a paid low-risk utility.

Buy Premium Licensing for Everybody

Compare actual use.

Frequently Asked Questions

1. What is SaaS sprawl?

SaaS sprawl is the uncontrolled or insufficiently governed growth of cloud applications, accounts, subscriptions, licenses, data, integrations, vendors, and identities. Having many applications is not automatically sprawl. The issue is whether the organization can explain why each application exists, who owns it, what it costs, who has access, what data it contains, and how it would be retired.

2. How many SaaS applications should a business have?

There is no universal correct number. One organization may operate effectively with 12 SaaS applications while another may legitimately require 80. The better measure is whether every application has a clear purpose, owner, user base, cost, security posture, dependency model, renewal process, and lifecycle plan.

3. Is having too many SaaS subscriptions bad?

Not necessarily. A large portfolio can be well governed. Problems arise when subscriptions are duplicated unintentionally, licenses remain unused, former employees retain access, renewal dates are unknown, data is scattered, or nobody understands why an application still exists.

4. How do I find all the SaaS subscriptions my company uses?

Start with several sources instead of relying on one system. Review accounts payable, corporate cards, expense reports, procurement records, contracts, identity providers, Microsoft Entra enterprise applications, Google Workspace connected apps, SSO platforms, OAuth grants, password managers, IT tickets, and department interviews.

5. What is shadow SaaS?

Shadow SaaS is software adopted outside normal IT, procurement, security, or finance visibility. It can include paid applications, free tools, browser-based platforms, AI services, and applications connected to company systems through OAuth.

6. Is free SaaS a security risk?

It can be. Price does not determine security risk. A free application may still store company documents, process customer information, request access to Google Workspace or Microsoft 365, or become an operational dependency. Review important free SaaS according to its data and business risk.

7. How can I find unused SaaS licenses?

Compare assigned users with meaningful usage, employment status, license tier, application activity, and business ownership. Possible candidates include seats belonging to former employees, duplicate accounts, and users with little relevant activity. Verify context before removing access.

8. Does no recent login mean a license is unused?

No. A user may be seasonal, an emergency administrator, or an occasional specialist. The account may also support API integrations or automations. Login history is useful evidence but should not be the only cancellation criterion.

9. How often should SaaS licenses be reviewed?

There is no universal review frequency. Review cadence should reflect cost, risk, workforce changes, contract structure, and application criticality. At minimum, significant applications should be reviewed in time to make an informed decision before their contractual renewal or notice deadline.

10. How should businesses manage SaaS renewals?

Track the renewal date and contractual decision deadline, notify the owner early enough to act, review meaningful usage, licensing tiers, business value, security, integrations, duplicate capabilities, and contract terms, then explicitly decide whether to renew, right-size, renegotiate, replace, or retire.

11. Should IT approve every SaaS purchase?

Not necessarily with the same process. A low-risk trial may justify lightweight review, while software processing sensitive data or supporting a critical business function deserves deeper IT, security, procurement, privacy, or legal evaluation. Governance should be proportional to risk.

12. Who should own a SaaS application?

A meaningful application should usually have a business owner who understands why the company needs it and a technical or administrative owner who understands access, configuration, identity, and integrations. Billing ownership should also be clear. These roles can belong to different people.

13. What is SaaS license rightsizing?

License rightsizing means aligning the number and level of licenses with actual business requirements. It may involve reclaiming unnecessary seats, moving appropriate users to lower tiers, or adjusting license quantity at renewal while preserving higher-level features for people who genuinely need them.

14. How do I know if two SaaS tools are duplicates?

Compare actual workflows instead of marketing descriptions. Identify users, features they rely on, integrations, customer requirements, data ownership, and specialized capabilities. Two applications in the same category may solve different business problems.

15. Should a company use both Microsoft 365 and Google Workspace?

Sometimes. Acquisitions, migrations, separate divisions, customer requirements, or specialized workflows may justify both. Running both without a clear operating model can also increase licensing, identity, file-sharing, and collaboration complexity. Understand the reason before consolidating.

16. Should a company use both Slack and Teams?

It depends. Review user groups, external collaboration, integrations, Microsoft licensing, existing workflows, and organizational communication patterns. Using both is not automatically wasteful, but unexplained duplication deserves investigation.

17. How do you safely cancel a SaaS subscription?

Treat important cancellations as small migration projects. Confirm owner approval, review the contract, identify users and integrations, export required data, move workflows, address retention, remove access, revoke relevant API or OAuth permissions, cancel the subscription, and verify billing.

18. What should happen to SaaS data before cancellation?

Identify what needs to be retained, export it in a usable format, verify completeness, preserve necessary attachments and metadata, and migrate it to the appropriate system. Follow applicable business, contractual, regulatory, and legal retention requirements.

19. How should SaaS access be removed when an employee leaves?

Review the primary identity provider plus direct SaaS accounts, admin roles, API tokens, OAuth grants, shared workspaces, licenses, and ownership of documents, automations, reports, and integrations. Do not assume disabling one Microsoft or Google account automatically removes every independent SaaS account.

20. What is SCIM?

SCIM is the System for Cross-domain Identity Management, a standard used by compatible identity platforms and SaaS applications to automate user and group provisioning, updates, and deprovisioning. It can improve account lifecycle management, but support varies by vendor.

21. What is SaaS FinOps?

SaaS FinOps applies collaborative financial-management practices to software subscriptions and SaaS consumption. It combines cost visibility with usage, ownership, forecasting, procurement, contracts, renewal planning, and business value rather than treating optimization as a simple cost-cutting exercise.

22. How do you manage AI software subscriptions?

Inventory AI applications separately, identify owners and users, review overlapping capability, understand what company data each platform can access, confirm current provider policies, review identity and administration options, map integrations, and remove former-user access.

23. Should a small business use SaaS-management software?

Not necessarily. A small environment may begin with a maintained inventory, renewal calendar, named owners, finance reconciliation, IT/security review, and an offboarding checklist. Dedicated SaaS-management software becomes more attractive as scale and complexity make manual tracking unreliable.

24. Can SimplyRem help reduce unnecessary SaaS subscriptions?

SimplyRem currently provides IT consulting, vendor and software selection, cloud cost optimization, cloud and collaboration administration, identity-related services, security review, and technology strategy that can support SaaS portfolio analysis. Recommendations should begin by understanding business value and dependencies rather than automatically canceling tools.

25. Can SimplyRem review Microsoft 365 or Google Workspace licensing?

SimplyRem's current Cloud Based Email Services & Collaboration Systems practice explicitly includes Microsoft 365 and Google Workspace deployment and administration, identity and provisioning work, tenant administration, governance, migration, and related licensing analysis. The exact review should depend on the organization's current tenant, contracts, users, and requirements.

Final SimplyRem CTA

Not sure how many SaaS subscriptions your company actually has—or why you're still paying for some of them?

The goal should not be to walk into the environment and start canceling software.

SimplyRem can help review the technology portfolio, application ownership, Microsoft 365 or Google Workspace environments, licensing, cloud costs, identity, security considerations, integrations, and overlapping technology capabilities, then help build a practical consolidation or cleanup plan where it actually makes sense. SimplyRem's current IT Consulting practice also explicitly states that its vendor and software recommendations are independent, with no reseller relationships or vendor kickbacks steering the recommendation.

Keep what earns its place. Consolidate where the evidence supports it. Replace what no longer fits. Retire what is truly unnecessary. Investigate what you don't understand yet.