Sanctioned vs Unsanctioned SaaS: How to Actually Govern Both Without Pretending the Line Holds

Sanctioned vs Unsanctioned SaaS: How to Actually Govern Both Without Pretending the Line Holds

Most security teams treat SaaS as two clean buckets: the apps you approved and the ones you didn't. In real life, that line moved months ago and nobody told IT. Sanctioned vs unsanctioned SaaS is the wrong question. The real question is which app instance you actually trust, who's signed in, and what data is leaving with them.

The line between sanctioned and unsanctioned is a fiction

You sanctioned Google Workspace. Marketing also has three free Notion accounts on personal Gmail. Sales is paying for an AI sales prospecting tool out of a corporate card and bypassing procurement. Engineering set up a personal GitHub for a side project that imports your repo.

Every one of those apps is somewhere on the spectrum between fully sanctioned and fully rogue. Most are sitting in the middle: company data, personal identity, no IT review, no DLP, no SSO, no offboarding. When the employee leaves, the data stays. When an attacker phishes them, the credentials work everywhere.

Treating SaaS as a binary makes you feel organized. It does not actually reduce risk.

What "sanctioned" should mean (and usually doesn't)

A real sanctioned app meets four conditions. It's behind your IdP via SSO. It uses your corporate tenant, not a personal account. It has DLP coverage for the data moving in and out. And there's an owner who reviews its access logs and offboards leavers.

Drop any one of those and the app slides into the gray zone. We see this constantly with Microsoft 365, Google Workspace, OneDrive, Slack, Notion, Canva, ChatGPT, and Claude. The corporate tenant exists. So does the personal account on the same employee's laptop. The browser cookies don't care which one is "sanctioned." Neither does the data.

If your asset inventory says "we use Notion" but doesn't say which tenants, you're tracking software, not security.

What "unsanctioned" actually looks like

Unsanctioned SaaS isn't usually a malicious tool. It's a free tier of something legitimate that an employee signed up for in five minutes. It's a personal Gmail somebody used to register for a trial. It's an AI app that wasn't on the roadmap two quarters ago and is now embedded in three workflows.

The risk profile is consistent: corporate data flows into an account your IT team can't see, can't disable, and can't audit. When the employee leaves, the account follows them. When a regulator asks where your customer data lives, you can't answer.

Shadow IT discovery is the first step, but discovery alone doesn't fix anything. You have to be able to act on what you find.

The governance stack that actually holds up

Governing both sides of the spectrum takes three controls working together, not one tool trying to do everything.

Layer 1: Discovery. A secure web gateway with visibility into SaaS use across the workforce. Not just domains. Specific apps, the accounts signing in, sanctioned vs personal, and how much traffic is going where. This is where you stop guessing.

Layer 2: Tenant restriction. Once you know what's out there, you have to be able to say: "Slack is allowed, but only our tenant. ChatGPT is allowed, but only the enterprise login. Personal Gmail is read-only or blocked outright." That's Cloud Application Control. One toggle. One policy. Same enforcement on every device.

Layer 3: Data inspection. Even inside sanctioned apps, sensitive data moves in directions you didn't plan. A PHI-tagged spreadsheet uploaded to OneDrive and accidentally shared externally is a sanctioned-tool risk. Endpoint DLP catches the upload before it leaves. CASB Neural scans data at rest in your SaaS tenants and flags publicly or externally shared files.

Discovery without enforcement is a wall of dashboards. Enforcement without inspection is a false sense of security. You need all three.

Where most teams trip

A few patterns we see, mostly from customers migrating off legacy SSE stacks.

Trying to do it all with DNS filtering. DNS can block a domain. It can't tell you whether the user logged in to your tenant or theirs, and it can't inspect what they uploaded. If "Google Drive" is allowed at the DNS level, both your-company.com Drive and personal.gmail.com Drive are open. That's not governance. DNS filtering vs SWG covers the gaps in detail.

Putting everything behind SSO and calling it done. SSO catches the apps that bothered to integrate. It misses the free tier of every new tool an employee opens this quarter. You still need a discovery layer at the network edge.

Buying a "CASB" that only sees what's in your tenant. A traditional CASB scans your sanctioned environment. That's useful for data at rest. It does nothing about the personal Notion account that imported your roadmap. You need shadow IT discovery and tenant control on top.

What "good" looks like

A few of our customers run something close to the model below. Outreach Health, a healthcare org with 5,000 to 10,000 employees and 34 offices, replaced their legacy SWG and got policy changes from days down to minutes. Greylock Partners moved from Cisco Umbrella to dope.security and closed in 27 days, partly because DNS filtering wasn't catching what their distributed VC team was actually using.

The pattern in both cases: discovery first, tenant control second, data inspection third, all in a single console. No data center round trip. No three vendors. No spreadsheets of "approved apps" that nobody updates.

A practical 30-day governance plan

If you want to actually move on this in the next month, here's the order of operations.

Week 1: Turn on SaaS discovery at the secure web gateway. Get an honest list of every app the workforce touches, ranked by traffic, broken out by sanctioned tenant vs personal.

Week 2: Pick the top ten apps by usage. For each, decide: corporate tenant only, allow personal with restrictions, or block. Push the policy from one console.

Week 3: Turn on data-at-rest scanning for the SaaS apps that hold sensitive data (OneDrive, Google Drive, Box). Remediate the publicly shared and externally shared files you find.

Week 4: Add endpoint DLP for data in motion. Cover uploads to personal accounts, AI tools, and webmail. Start in monitor mode. Move to block once you have a baseline.

Four weeks. Three layers. One console. That's the work.

Stop arguing about the list. Govern both sides.

Sanctioned vs unsanctioned SaaS is a useful framing for an asset spreadsheet. It is not a security control. The control is being able to see what's used, restrict who can access what tenant, and inspect what data moves in and out, on every device, all the time.

That's the dope.security model. Agent-based, on-device, one console, no backhauling. Try it on a couple of laptops this week.

Start a free trial of dope.security or book a 20-minute demo.

Shadow IT
Shadow IT
Cloud App Control
Cloud App Control
CASB
CASB
Secure Web Gateway
Secure Web Gateway
back to blog Home