How to Secure SaaS Tools When Every Department Buys Its Own Software

A practical guide to controlling SaaS sprawl, shadow IT, OAuth risk, data exposure, and departmental software buying without slowing the business down.

TL;DR

SaaS security becomes difficult when software buying spreads across the business faster than IT and security can see it. Marketing connects automation tools, sales adds CRM extensions, HR adopts hiring platforms, finance brings in payment and expense software, and employees authorize third-party apps through Google or Microsoft accounts. Each decision may be reasonable on its own, but together they create a much larger identity and data surface than most companies realize.

A strong SaaS security program starts with visibility and ownership. The company needs to know which applications are in use, what data they hold, who administers them, which apps can access corporate identities, and what happens when users or vendors leave.

SSO, MFA, OAuth controls, access reviews, logging, offboarding, data-sharing rules, and vendor review then sit around that visibility. The goal is not to stop departments from buying useful software. It is to make sure the business knows what it has bought, what each tool can reach, and where the real risk sits.

Definition

SaaS security is the discipline of protecting business applications, identities, and data that sit outside traditional corporate infrastructure. In practice, that means understanding which SaaS tools are being used, who owns them, what information they store, which users and third-party apps can access them, and how permissions change as people join, move roles, or leave.

The difficult part is rarely the application itself. The real exposure often sits in the connections around it: OAuth permissions granted to another app, shared administrator accounts, broad external sharing, stale users, unmanaged browser sessions, or customer data copied into tools that were never formally reviewed. Good SaaS security is therefore less about creating a giant approved-software list and more about keeping identity, access, data, and ownership visible as the software estate changes.

Key Takeaways

• SaaS sprawl becomes a security problem when the company loses visibility into applications, data, administrators, and third-party access.
• Identity is usually the control point. SSO, MFA, role-based access, OAuth governance, and strong offboarding reduce a large share of SaaS exposure.
• Departmental buying does not need to be blocked, but every important application should have an owner, a data classification, and a clear access model.
• OAuth-connected apps deserve the same scrutiny as direct user access because they can retain persistent access to email, files, calendars, and other business data.
• The strongest SaaS programs make discovery, access review, vendor review, logging, and offboarding part of normal operations rather than a once-a-year cleanup exercise.

SaaS Sprawl Is Now an Identity and Data Problem

The security problem with SaaS is rarely the software purchase itself. It is what happens after the purchase, when a new tool is connected to Google Workspace or Microsoft 365, given access to files or calendars, populated with customer data, assigned an administrator, and then quietly absorbed into daily work.

Once that happens across marketing, sales, finance, HR, engineering, and operations, the company can end up with dozens or hundreds of applications holding pieces of the business without any single team having a complete view.

This is why SaaS sprawl has become less of a procurement issue and more of an identity and data problem. A marketing tool may hold lead data and OAuth access to email. A recruiting platform may contain candidate information and employee records.

A sales extension may sit inside the CRM and inherit access to customer conversations. A project tool may hold client documents long after a contract ends. Each system may be useful and legitimate, but the risk comes from how many identities, permissions, integrations, and data copies accumulate around them.

The 2023 Okta support-system breach is a good example of why those relationships matter. Attackers gained access to files uploaded to Okta’s customer support system, and some of those files contained session tokens that could be used to access customer environments.

The important point is not that support software is uniquely risky. It is that operational SaaS systems can hold highly sensitive identity artefacts and become part of the attack path even when they sit outside the company’s core production environment.

For a growing business, the practical challenge is therefore visibility. The company needs to know which SaaS applications are in use, who owns them, what data they contain, which identities can access them, which external apps are connected through OAuth, and what happens to those permissions when people or vendors leave.

Once that visibility exists, controls such as SSO, MFA, access reviews, logging, offboarding, vendor review, and data-sharing rules become much easier to apply where the risk is actually highest.

The aim should not be to force every software decision through a slow central approval process. That usually drives employees toward more shadow IT, not less. The stronger model is to let teams move quickly while keeping sensitive applications, privileged access, data flows, and third-party connections visible enough that security can intervene before convenience turns into exposure.

Shadow IT Usually Starts as a Visibility Problem

Most shadow IT begins with a reasonable business decision. A team needs to launch a campaign, automate a workflow, share files with a client, analyze data, or test an AI tool, and the fastest route is often a SaaS product that can be activated with a credit card and a Google or Microsoft login.

By the time security becomes aware of it, the application may already hold customer information, internal documents, API keys, employee data, or privileged integrations. The risk develops quietly because modern SaaS adoption is designed to remove friction from buying and connecting software.

The harder issue is that procurement records rarely show the whole estate. Free trials, employee expense cards, browser extensions, OAuth grants, and tools purchased directly by departments can sit outside the systems finance or IT normally tracks.

A company may know what it pays for and still have limited visibility into what employees have authorised. That gap matters because an application does not need a formal contract to become part of the security perimeter. If it can read company email, access files, sync CRM data, or act through a user’s identity, it already has a meaningful relationship with the business.

OAuth makes this particularly easy to underestimate. A user can approve an application to access mail, calendars, contacts, files, or other services without handing over a password. The experience feels safer because credentials are not being shared, but the resulting token can provide persistent access until the grant is revoked.

Microsoft’s own guidance on investigating risky OAuth applications reflects how these permissions can become a security issue when users authorise applications that request broad access or behave unexpectedly.

For a growing company, SaaS discovery therefore needs to reach beyond the official vendor list. Identity logs, OAuth grants, SSO integrations, browser activity, expense records, network telemetry, and conversations with business teams can all reveal different parts of the estate.

The objective is not to produce a perfect catalogue of every tool employees have ever opened. It is to identify the applications that can reach sensitive data, privileged identities, important workflows, or large groups of users, then make sure each one has an owner and an appropriate level of control.

OAuth Access Can Become a Quiet Back Door

SaaS risk becomes harder to see when applications start acting through other applications. A user may connect a productivity tool to email, storage, calendar, or CRM data with a few clicks, and from that point the third-party app can operate with permissions the employee may barely remember granting. No password has been shared, but meaningful access has still been created.

The risk depends less on the existence of OAuth itself and more on the scope and persistence of the permission. An application that can read basic profile information is one thing. An application that can read mailboxes, download files, modify content, or act on behalf of a privileged user is something else entirely. The problem becomes sharper when those grants survive long after the original business need disappears.

A useful real-world example came from the CircleCI security incident disclosed in 2023, where attackers gained access through a compromised employee laptop and were able to extract data that included customer secrets and environment variables.

The incident was not an OAuth breach in the narrow sense, but it shows why trusted application access, tokens, secrets, and machine-to-machine permissions deserve the same scrutiny as user passwords. Once an attacker obtains a valid credential or token, the surrounding systems may treat malicious activity as legitimate access.

For growing companies, the practical control is to make third-party application access visible and reviewable. High-risk permissions should require stronger approval, dormant integrations should be removed, privileged identities should face tighter rules, and application access should be reviewed when employees leave or change roles. The objective is not to make SaaS integrations difficult. It is to stop yesterday’s convenient connection from becoming tomorrow’s invisible access path.

Offboarding Is Where SaaS Access Often Lingers

SaaS risk often survives an employee longer than the employment relationship itself. Disabling the corporate email account is only part of the job if the person also had direct logins to project tools, CRM platforms, file-sharing systems, analytics products, support software, developer services, or applications purchased outside central IT.

The more decentralised the software estate becomes, the easier it is for access to remain active simply because nobody outside the department knew it existed.

Role changes create a similar problem. Someone who moved from operations into sales six months ago may still retain administrator rights from the previous role, while contractors accumulate access across successive projects because each permission was reasonable when it was granted.

Over time, the SaaS estate fills with accounts that are legitimate individually but excessive collectively. The security issue is privilege accumulation rather than a dramatic control failure.

A clean offboarding process therefore has to follow identity beyond the primary directory. SSO makes that considerably easier because disabling one central identity can remove access across connected applications, but many growing companies still have direct SaaS accounts, local administrators, service accounts, shared credentials, and applications that were never integrated with the identity provider. Those are the places where manual ownership still matters.

The useful control is simple: every important SaaS application should have a named owner, and that owner should be able to account for active users, administrators, external collaborators, and non-human accounts.

Offboarding should revoke sessions and application access as well as the central identity, while periodic access reviews catch the permissions that role changes and temporary projects leave behind. In a SaaS-heavy business, access rarely becomes dangerous because someone deliberately ignores security. It becomes dangerous because yesterday’s legitimate permission quietly outlived its purpose.

Finance Data Is One of the Best SaaS Discovery Signals

Some of the most useful SaaS visibility sits outside IT altogether. Finance sees software through card payments, reimbursements, recurring subscriptions, vendor names, departmental budgets, and renewal notices, often before security knows the application exists. That makes financial data a surprisingly effective early-warning system for SaaS sprawl.

The value is not in turning finance into a security function. It is in using spend data to surface tools that may otherwise stay invisible until they are deeply embedded. A recurring charge from a new software vendor can indicate a new data processor, a new integration, or a workflow that has become important enough for a team to pay for directly.

Several departments paying separately for the same product can reveal fragmented ownership. A subscription continuing after the original buyer has left can point to an orphaned application that still holds company data.

Finance also has something security teams often lack: a natural view of renewal. That moment is useful because it creates a reason to ask whether the tool still has an owner, whether it still needs the data it holds, whether user access has been reviewed, and whether the vendor or product has changed materially since the original purchase. SaaS risk often grows quietly over time, so a renewal can become a practical checkpoint without creating another artificial review cycle.

For growing companies, the strongest approach is to connect finance signals with identity and application discovery rather than expecting either system to provide the whole picture. Spend tells you what the business is paying for. Identity tells you what users are signing into.

OAuth and browser discovery reveal what is being connected. Department owners explain what the application actually does. Put together, those signals make it much harder for a business-critical SaaS tool to remain invisible until something goes wrong.

SaaS Policy Should Make Safe Buying Easier

A SaaS policy only works if people can use it without decoding compliance language. Most employees are not trying to create shadow IT. They are trying to solve a problem quickly, and if the approved route feels slow or vague, they will often choose the tool first and ask questions later. A useful policy should therefore make the safe route obvious before a team has already uploaded data, invited users, or connected the app to core systems.

The important questions are practical. Can a team start a free trial? What kind of company or customer data can be uploaded? When does a tool need security review? Can it connect to Google Drive, Slack, CRM, or other business systems? Are external collaborators allowed? Can AI features process client calls or internal documents? Those decisions should be clear enough that a marketing manager or recruiter can make the right call without involving security in every low-risk purchase.

The level of scrutiny should rise with the exposure. A simple productivity tool that holds no sensitive data should not go through the same review as payroll software, a CRM integration, or an AI meeting platform recording customer conversations. The policy should help people recognise when the risk has changed, particularly when an application begins handling confidential data, gains broad permissions, or becomes important enough that an outage would disrupt the business.

Done well, the policy becomes part of how teams buy and use software rather than a document they remember only during an audit. Employees know where the boundaries are, security gets involved earlier on the decisions that matter, and low-risk software does not spend weeks waiting for approval. That balance is what keeps SaaS governance usable as the company grows.

A Practical SaaS Risk Tiering Model

Not every SaaS tool deserves the same level of scrutiny. Treating a simple utility app the same way as payroll, CRM, or an identity platform creates unnecessary friction and eventually encourages teams to bypass the process. The more useful approach is to judge the application by the data it touches, the access it receives, and how important it becomes to the business.

A low-risk tool may hold little or no sensitive data and operate without privileged integrations. A business workflow app might sit inside marketing, recruiting, or project delivery and therefore need an owner, MFA, access reviews, and some vendor scrutiny. Once an application holds customer records, employee information, financial data, code, legal material, or confidential conversations, the control level should rise sharply because the consequences of misuse or failure are much larger.

The highest scrutiny belongs to platforms that sit at the centre of identity, communication, finance, data, or integration. Email suites, identity providers, ERP platforms, collaboration tools, data warehouses, backup systems, and integration hubs often have broad permissions and large blast radiuses. A compromise in one of these systems can affect dozens of other applications at once, so stronger administration, monitoring, recovery planning, and change control are justified.

The advantage of tiering is that it keeps governance proportionate. Security teams can spend their time on applications where a failure would materially affect data, operations, or trust, while lower-risk tools move quickly. The classification should also be able to change. A lightweight app can become high-risk once a department starts uploading customer data, connecting it to core systems, or relying on it for a critical workflow.

What to Check Before Approving a SaaS Tool

A good SaaS review should answer a small number of questions before the tool becomes embedded in the business. The first is about data. What will the application store, process, generate, or export? A lightweight app can become high-risk very quickly if a team starts feeding it customer records, employee information, source code, legal material, or confidential call transcripts.

The next question is about access. Does the application support SSO and MFA? Can roles be limited properly? Are administrator accounts separated? Can users be removed automatically when they leave? If the tool connects to other systems, the integration deserves the same scrutiny as the user account. A SaaS product with broad access to email, files, CRM, or cloud storage may create more exposure through its permissions than through the application itself.

Vendor maturity matters more once the application becomes important to the business. Security documentation, breach-notification terms, sub-processors, audit evidence, data location, retention, and deletion rights should be clear enough that the company knows what happens during an incident and at the end of the relationship. For higher-risk tools, it is also worth understanding whether AI features use customer content for training or rely on additional sub-processors that were not part of the original review.

The final question is ownership. Someone inside the company should know why the tool exists, who administers it, who reviews access, who handles renewal, and who can decide when it should be retired. That matters because SaaS risk often becomes visible long after purchase, when the original champion has moved on and the application is still holding live data. A good approval process should therefore be short enough to use, but complete enough to make those future decisions obvious.

SaaS Security Works When Visibility Keeps Pace With Buying

Department-led SaaS buying is not going away, and trying to centralise every software decision would probably create more shadow IT rather than less. The more realistic job is to keep visibility, identity, data access, and ownership moving at roughly the same speed as adoption.

That means knowing which tools matter, which ones can reach sensitive data, who owns them, how users and integrations gain access, and what happens when the relationship ends. The companies that manage SaaS well are not the ones with the longest approved-app list. They are the ones that can tell, with reasonable confidence, where important data sits and who can still reach it.

Once that visibility exists, the rest becomes much easier. High-risk tools receive stronger controls, lower-risk tools move quickly, OAuth and external sharing become reviewable, offboarding becomes more reliable, and renewals become useful checkpoints instead of automatic payments. The security model stays proportional to the business rather than becoming another layer of bureaucracy.

FAQs

1. Is shadow SaaS always bad, or is it just part of modern work?

Shadow SaaS is not automatically bad. In many cases, it appears because business teams are trying to solve real problems faster than the official tool stack allows. A marketer testing a landing page builder, a recruiter using a scheduling tool, or a finance analyst trying a reporting add-on may be acting in the company’s interest. The risk begins when the tool starts holding business data without ownership, access control, vendor review, retention rules, or offboarding.

The smarter approach is to reduce dangerous invisibility, not to punish useful experimentation. Companies should create a low-friction intake path where teams can disclose new tools early, get quick guidance, and move through a risk-based review. If the security process is practical, people are more likely to use it before the tool becomes embedded.

2. What is the first thing a small company should do if it has no SaaS inventory?

Start with the sources that already exist: finance spend, corporate card records, SSO applications, browser extensions where visible, email domains, procurement records, password manager vaults, and department heads. You do not need a perfect discovery tool on day one. You need a first map of the applications most likely to hold customer, employee, finance, legal, product, or client data.

Once the list exists, sort tools by risk rather than by alphabetical order. Find the apps with sensitive data, external sharing, admin privileges, integrations, and business-critical workflows. Those are the tools that need owners, SSO, MFA, access reviews, and vendor checks first. The long tail can be handled later with lighter controls.

3. Should every SaaS tool go through a security review?

Every tool should be visible, but every tool does not need the same review. A lightweight utility that stores no company data should not be forced through the same process as payroll, CRM, email, HR, legal, finance, or AI transcription software. Over-reviewing low-risk tools slows the business and encourages teams to bypass security.

A tiered model works better. Low-risk tools get basic rules. Medium-risk tools get ownership, SSO where practical, vendor checks, and access review. High-risk tools get full security, legal, privacy, and operational review. The aim is to match effort to exposure.

4. Why is OAuth such a big issue in SaaS security?

OAuth lets one app access another app on a user’s behalf. That is useful for productivity, but risky when the permission is broad, poorly understood, or never reviewed. A small app can request access to files, email, calendars, CRM data, or user profiles, and users may approve the connection because it looks routine.

The risk is that OAuth grants can become persistent data access routes. Security teams should review which apps are connected, what permissions they requested, who approved them, whether the app is still used, and whether the permission level is justified. High-scope permissions should need stronger review.

5. How do we secure SaaS without blocking departments from buying tools?

The best control is not a flat ban. It is a fast, clear intake process with pre-approved tools, risk tiers, and practical guardrails. Departments should know which tools are already safe to use, what data they can upload, when they need review, and how long approval normally takes. If security is slow and vague, teams will route around it.

Security should also work with department leaders before purchases happen. Marketing, sales, HR, finance, and operations can nominate upcoming tool needs, while IT and security can suggest safer options, standard contract language, and integration patterns. This turns SaaS security from policing into operating support.

6. What should we ask vendors before buying a SaaS tool?

Ask what data the tool will store and process, where it is hosted, whether it supports SSO and MFA, how roles work, whether audit logs are available, what third-party sub-processors are involved, how vulnerabilities are handled, how incidents are reported, and what happens to data after termination. For AI-enabled tools, ask whether customer content is used for training, improvement, or human review.

The questions should match the risk. A tool that handles public design references does not need the same review as an HR, finance, CRM, legal, support, or AI meeting platform. High-risk vendors should provide stronger evidence, including security documentation, privacy terms, audit summaries, and clear operational commitments.

7. What are the most dangerous SaaS settings to ignore?

The most dangerous settings are usually the quiet ones: external sharing, public links, guest access, admin roles, local accounts outside SSO, weak recovery methods, unrestricted exports, long session duration, unreviewed OAuth grants, disabled audit logs, and default retention. These settings rarely look dramatic until something goes wrong.

A monthly SaaS hygiene review should focus on these settings in the most sensitive tools. The company does not need to check every setting in every app every week. It needs a repeatable review for the applications where data exposure would cause real harm.

8. Who should own SaaS security: IT, security, finance, or each department?

No single team can own the whole problem. Departments own the business use and data context. IT owns identity, provisioning, integrations, and administration. Security owns risk standards, monitoring, exceptions, and incident response. Legal and privacy own contractual and regulatory issues. Finance and procurement own spend visibility, renewal discipline, and vendor records.

The practical mistake is leaving ownership implicit. Every meaningful SaaS tool should have named owners and clear responsibilities. When an alert fires, a user leaves, a vendor changes terms, or a renewal comes up, the company should know who decides and who acts.

9. How often should SaaS access reviews happen?

Critical SaaS tools should be reviewed at least quarterly, and privileged access should be reviewed more frequently when the environment changes fast. Medium-risk tools can often be reviewed semi-annually or at renewal. Low-risk tools may only need basic ownership and acceptable-use checks unless their data use changes.

Access reviews should not be box-ticking exercises. Review admins, external users, inactive users, contractors, shared accounts, service accounts, high-risk groups, and users who changed roles. The review should result in removals, role reductions, ownership updates, or documented exceptions.

10. What is the simplest sign that SaaS risk is getting out of control?

One clear sign is when nobody can answer which tools hold customer, employee, finance, legal, or product data. Another is when offboarding depends on each department remembering every app a person has ever used. A third is when software renewals happen without confirming ownership, access, data use, or business need.

SaaS risk becomes manageable when visibility, ownership, access control, and renewals are connected. The company does not need to become bureaucratic. It needs to know where its data is, who can reach it, which vendors process it, and how access is removed when people, tools, and business needs change.