Shadow IT discovery: a practical playbook, with real SWG screenshots

The average mid-market company has somewhere between 200 and 800 SaaS apps in use, depending on who's counting. IT typically knows about 40 to 80 of them. That gap is shadow IT.

Every article on shadow IT tells you this. Not many tell you how to actually find it, classify it, and get to governance without setting off a company-wide fire.

This is the playbook. Six steps. Real workflow. The kind you run in a quarter and reuse every three months after that.

Step 1: Pull a clean 30-day SWG log

You're looking for every outbound cloud destination across every user, with enough fidelity to distinguish corporate accounts from personal ones.

Minimum fields:

• Timestamp. For frequency and time-of-day patterns.
• User. Either authenticated identity or device ID, mapped to a person.
• Destination domain. Full hostname, not just the apex domain.
• URL category. For the first-pass filter.
• OAuth provider (where present). Tells you whether the sign-in was corporate or personal.
• Bytes transferred. Proxy for how intensively the tool is being used.

If your SWG is agent-based and does SSL inspection on-device, you already have all of this. If it's a cloud proxy, you'll get most of the fields but may lose OAuth provider detail on certain SaaS flows. Work with what you have.

30 days of data is the right window. Less and you miss monthly patterns. More and the analysis gets heavy.

Step 2: Classify by account type

This is the step most orgs skip, and it's where the real signal is.

Group every access event into one of three buckets:

Corporate account. The user signed in with their company identity (SSO through your IdP, corporate OAuth). The tool is probably sanctioned, or at worst tolerated. Governance applies.

Personal account. The user signed in with a personal Google, Microsoft, or direct account. The tool is outside your governance layer, even if the destination looks the same.

No identifiable sign-in. Public endpoints, anonymous usage, or tools where the account detection isn't reliable. Triage separately.

The personal-account bucket is where most of the real shadow IT risk lives. Someone using ChatGPT through a corporate tenant is governable. The same person using ChatGPT through their personal Gmail is not, even if the URL in the logs looks identical.

In dope.console, SWG logs include OAuth provider detection for the major SaaS platforms, so this classification is more or less automatic.

Step 3: Have the conversation before you block anything

Don't start shutting things off. That's how security teams lose political capital.

Pull the top 30 unsanctioned tools by user volume. For each, figure out who uses it and why. A Slack DM to the team lead usually works: "Hey, I see your team uses [tool] regularly. What's the use case? Is there an enterprise version we should be looking at?"

You'll learn three things:

• Which tools are solving a real problem the sanctioned stack can't. Those need to get added, not blocked.
• Which tools have a corporate version the team didn't know about. Those need a migration plan.
• Which tools are pure convenience, with an actual risk footprint, and no strong reason. Those are block candidates.

This conversation also gets team leads bought into the governance process. When the block eventually happens, it's not a surprise from security. It's a decision they were part of.

Step 4: Risk-rank with a simple matrix

Take every unsanctioned tool and score it on three axes:

AxisLow (1)Medium (2)High (3)Data sensitivityPublic content onlyInternal-only infoCustomer PII, PHI, PCI, source code, IPUser count1–5 users6–50 users50+ usersCompliance exposureNoneSome (industry-specific)High (HIPAA, PCI-DSS, SOC 2)

Multiply the scores. Range: 1 to 27.

• 1–6: Low risk. Document and move on.
• 7–15: Medium risk. Add to the governed list, apply SSO if possible, monitor via CAC.
• 16–27: High risk. Migrate to an approved alternative, or block.

Don't over-engineer this. A spreadsheet works. The goal is consistent triage, not precision.

Step 5: Enforce at the right layer

You have three enforcement layers. Use the least restrictive that actually solves the problem.

Allow with corporate-tenant restriction (CAC). Best outcome. Users keep using the tool. You know they're in a governed tenant with admin controls, audit logs, and data residency. Apply this everywhere you can.

Warn banner. Users hit an interstitial before proceeding. Good for emerging tools or categories where you want to raise awareness without blocking.

Block. Use sparingly. Block is appropriate when the tool has failed a security review, has known data practices you can't live with, or has no corporate-tenant path. Blocking should always come with a communicated alternative.

Cloud Application Control (the tenant-level restriction) is the layer most SWGs don't expose. It's the single highest-leverage enforcement move you can make, because it lets you say yes to more tools while keeping them inside your governance boundary.

Step 6: Measure what changed

After 60 to 90 days, check the metrics that matter.

Ticket volume. Shadow IT enforcement usually reduces IT tickets related to SaaS access, because users know what's approved. Outreach Health, one of our customers, saw a 70% reduction in web-access-related tickets within 90 days.

Blocked attempts. A high blocked-attempts number on a specific tool is a signal: either the block is wrong, or your team is still missing a sanctioned alternative.

Repeat offenders. A small group of users who keep hitting the blocks usually need a direct conversation and sometimes a training. Don't treat them as a data point. Treat them as a sign that communication broke somewhere.

New unsanctioned tools. Should be going down over time, not up. If it's going up, re-examine your sanctioning process: it's probably slower than your workforce.

Five real shadow IT examples

Anonymized from recent deployments.

AI note-taker joining Zoom meetings. 120 users across three departments. Nobody had approved it. It was joining meetings with outside customers. Risk rank: high (confidentiality). Resolution: migrated to the M365 Copilot alternative that was already licensed.

Personal Dropbox for client file delivery. 15 sales reps. They'd gotten frustrated with the approved tool's link expiration. Risk rank: medium. Resolution: fixed the expiration policy on the approved tool, killed the Dropbox workaround.

A bespoke BI tool with production DB credentials. Two data engineers, one contractor. Running the backend locally on laptops. Risk rank: high (credentials). Resolution: migrated to a properly secured internal deployment in the same week.

Free versions of design tools. 40 marketers. Non-sensitive content. Risk rank: low. Resolution: documented, left alone, flagged for migration during the next tool refresh.

Personal accounts on an approved tool. 200+ users, all on corporate devices. Risk rank: medium (governance gap even though the tool was approved). Resolution: CAC policy restricting to the corporate tenant.

The pattern holds: most shadow IT is convenience or a gap in the sanctioned stack, not malice. Fix the gap, not the user.

A one-page policy your org can use

Template structure:

Principle. Employees can use SaaS tools that solve real problems, as long as the tools operate within our governance boundary.

Sanctioned. The current list of approved tools, with owners and review dates.

Requested. A clear path to request a new tool, including SLA (we aim for a decision in 10 business days).

Restricted. Tools usable only through corporate tenants and SSO.

Blocked. Tools blocked entirely, with the reason and a pointer to the approved alternative.

Publish it. Update it quarterly.

Where dope.security helps

Short version: dope.SWG inspects SSL traffic on-device, so the logs have everything you need for shadow IT discovery including OAuth provider detection. Cloud Application Control gives you tenant-level restriction on the major SaaS platforms. Dopamine DLP handles the prompt-content layer. All in one console.