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

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.

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.

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?
