The Hidden Security Risks in Your SaaS Stack


How many SaaS applications does your business use? If you answered “a dozen or so,” you’re probably underestimating. Research suggests the average small business uses 100+ SaaS applications, many of which IT never approved or even knows about.

Each one is a potential security vulnerability.

The SaaS Security Problem

SaaS has been great for business agility. Need a new tool? Sign up, pay monthly, start using it. No servers to buy, no software to install.

But this ease of adoption has security consequences:

Data sprawl. Your business data is scattered across dozens of cloud services. Customer information in the CRM. Financial data in accounting software. Documents in cloud storage. Employee details in HR tools.

Inconsistent security. Each SaaS provider has different security practices. Some are excellent. Some are terrible. You’re trusting all of them with your data.

Shadow IT. Employees sign up for tools without IT involvement. Marketing uses this analytics tool. Sales uses that contact finder. Finance uses some invoice automation. IT doesn’t know, can’t manage security, and can’t even account for what data is where.

Integration risks. SaaS apps integrate with each other. Give one app access to your email, and it might share that access with another service. Permission chains get complex and hard to audit.

Credential management. Each SaaS app needs credentials. Without a password manager and proper offboarding, you’ve got passwords everywhere, including in the heads of former employees.

Where the Risks Hide

Authentication and access:

  • Apps without MFA (or MFA you haven’t enabled)
  • Shared accounts rather than individual logins
  • Former employees who still have access
  • Excessive permission grants

Data handling:

  • Apps storing sensitive data you didn’t expect
  • Data export features anyone can use
  • Third-party AI features that send data to external systems
  • Inadequate backup and recovery options

Integration points:

  • OAuth connections to other apps
  • API keys with overly broad permissions
  • Webhooks sending data to unexpected places
  • SSO misconfigurations

Vendor security:

  • Apps with poor security practices
  • Vendors without breach notification commitments
  • Free tiers with less security than paid versions
  • Startups that might not survive (and might not protect data when they don’t)

Taking Back Control

Step 1: Discover what you’re actually using

You can’t secure what you don’t know exists. Methods to discover SaaS usage:

  • Check credit card and expense statements for SaaS subscriptions
  • Review SSO and OAuth connections in Microsoft 365 or Google Workspace
  • Ask teams what tools they use (with amnesty for shadow IT)
  • Use a SaaS discovery tool if you want automation

Create an inventory: app name, purpose, data it holds, who uses it, who administers it.

Step 2: Assess the risk

For each application, consider:

  • What data does it have access to?
  • How sensitive is that data?
  • What would happen if this app was breached?
  • What security controls does it offer?
  • What are the vendor’s security practices?

Prioritise high-risk applications (sensitive data, broad access) for immediate attention.

Step 3: Establish baseline security requirements

Define what you require from SaaS apps:

  • MFA must be supported and enabled
  • Enterprise SSO integration (for critical apps)
  • Audit logging available
  • Data export capability for backup purposes
  • Breach notification commitment
  • Acceptable security certifications (SOC 2, ISO 27001)

New apps should meet these requirements before adoption.

Step 4: Clean up current mess

  • Enable MFA on everything that supports it
  • Remove access for departed employees
  • Review and reduce permissions
  • Disable or decommission apps that aren’t needed
  • Migrate data from risky apps to better alternatives

Step 5: Establish ongoing governance

  • Approval process for new SaaS applications
  • Regular access reviews (quarterly minimum)
  • Monitoring for shadow IT
  • Vendor security reviews for critical apps
  • Offboarding procedures that include SaaS access removal

Specific Recommendations

For critical business apps (email, accounting, CRM):

  • Require MFA without exception
  • Use SSO integration if available
  • Enable maximum audit logging
  • Regular access reviews
  • Backup data independently of the SaaS provider

For collaboration tools (Slack, Teams, file sharing):

  • Control external sharing capabilities
  • Review guest access regularly
  • Monitor for sensitive data in public channels
  • Enable message retention appropriate to your needs

For productivity tools (task management, notes, etc.):

  • Verify data residency if it matters
  • Check what integrations users have enabled
  • Ensure credentials are in your password manager

For AI and automation tools:

  • Review what data they access
  • Understand where data goes for processing
  • Check data retention policies
  • Be especially careful with tools that request broad permissions

The Vendor Assessment Question

Should you formally assess every SaaS vendor’s security?

For most SMBs, full vendor assessments for every app aren’t practical. Instead:

For high-risk apps (sensitive data, critical function):

  • Request SOC 2 or ISO 27001 certification
  • Review their security page and documentation
  • Ask about breach notification procedures
  • Check breach history and responses

For medium-risk apps:

  • Review their security documentation
  • Verify they support MFA
  • Check their breach notification policy

For low-risk apps:

  • Basic due diligence
  • Ensure they’re reputable
  • Keep data minimal

Don’t let perfect be the enemy of good. Some assessment is better than none.

The Free Tool Trap

Free SaaS tools are especially risky:

  • Less investment in security
  • Your data might be the product
  • Features might be removed or monetised
  • Less accountability for breaches
  • May have less favourable terms of service

If a tool is critical to your business, pay for it. Free tools for non-sensitive, non-critical uses can be acceptable with eyes open.

Building a Culture

Beyond controls, build awareness:

  • Educate staff on why SaaS security matters
  • Make it easy to request new tools through proper channels
  • Don’t punish people for past shadow IT - encourage disclosure
  • Share when you discover risky situations (without blame)

People will work around security if it’s too restrictive. Make the secure path the easy path.

The Long-Term View

Your SaaS stack will keep growing. New tools, new features, new risks. The goal isn’t to lock it down completely - that’s not realistic. The goal is:

  • Visibility into what tools are in use
  • Appropriate security on tools with sensitive data
  • Processes that scale as you grow
  • Culture that thinks about security when adopting tools

SaaS is here to stay. Your security approach needs to account for it.