AspharTech Solutions
Menu

Navigation

Explore AspharTech solutions, services, and resources.

SaaS risk management

Securing business-owned SaaS (without slowing them down)

Marketing, HR, finance, innovation… every team adopts online tools to move faster. The issue: these applications often contain sensitive data but are neither inventoried, nor reviewed, nor properly deprovisioned. Here’s a simple way to regain control.

Last updated: 1 November 2025 · AspharTech Solutions

SaaS security dashboard
Business SaaS
Why this matters: SaaS chosen directly by business teams often falls outside standard M365/Google controls but still processes customer, HR or financial data. That’s where “ghost accounts” are born.

1. Build a realistic inventory of the apps actually in use

The first mistake is starting from the list of applications paid for by IT. In many organisations, 20–40% of the SaaS used day-to-day were activated directly by business teams (credit card, free trial, partner account).

Your inventory should therefore cross multiple sources: authentication logs (SSO, Entra ID, Google), invoices, what business teams declare — and sometimes even endpoints (browser history or agent). The goal is not to spy but to understand what data leaves your core ecosystem.

Inventory of SaaS applications by department

Example inventory view: “department” column, “data type” column, “last activity” column.

2. Classify SaaS so you don’t apply the same rules to every tool

This is what prevents you from “blocking the business” on small tools.

Once you have an inventory, the most effective approach is to group applications by sensitivity level. A 3-tier model is usually enough:

  • Level 1 – critical: customer data, HR data, financial data, health data, employee records.
  • Level 2 – business: team collaboration tools, lightweight CRM, project management tools.
  • Level 3 – convenience: small utilities, design tools, individual productivity.

This step is key for leadership: it allows you to say “we’re not going to block your tools — but we will properly secure the ones that really handle sensitive data.”

3. Secure onboarding — and especially offboarding

This is the weak spot in almost every organisation.

When someone leaves the company, IT usually disables M365 / Google. But if that person created external business SaaS accounts, these access rights often remain active. That’s what we call an orphaned SaaS account.

A good practice is to perform a “linked account check” at offboarding time, then transfer content or disable accounts accordingly.

Offboarding workflow for SaaS accounts

Typical workflow: HR departure → IT checklist → SaaS review → deactivation or transfer.

4. Centralise what you can (SSO, M365, Google Workspace)

Even if not everything goes through SSO, you should capture as many signals as possible.

The more business applications are connected to your central directory (Entra ID / Azure AD, Google Identity, Okta…), the easier it becomes to review access. In organisations just getting started, we first target sensitive apps and those used by a large number of users.

Conclusion

Securing business-owned SaaS is not a “brutal” project that cuts tools overnight. It’s a visibility exercise, a classification effort and an alignment exercise with business leaders. Once the inventory is in place, automation becomes an obvious next step (access review, offboarding, alerts on inactive accounts).

This topic often comes up alongside privacy regulations (like Quebec’s Law 25) or during a M365 security audit, because the underlying questions are the same: where is the data — and who has access?

AspharTech Solutions — Cybersecurity firm based in Montreal