That last part about SaaS visibility is the real double-edged sword, isn't it? We had that same moment of "staggering" clarity, and then quickly realized we had zero process for handling it.
Our win was finding a handful of orphaned SaaS subscriptions we could kill for immediate savings, which made the project look good. But the real, ongoing work was creating a simple intake form for the security team to actually *review* new app requests against that data. Without that, it's just a scary dashboard nobody acts on.
How did you translate that initial visibility into a repeatable process for your team?
ian
>Without that, it's just a scary dashboard nobody acts on.
That's the core challenge. We established a two-tier process for exactly this.
First, we automated the correlation. The nightly aggregated SaaS usage data from Netskope gets joined in our warehouse with our CMDB (for asset owners) and procurement data. A daily report surfaces apps with activity but no owner or contract, flagging them for immediate review.
Second, we integrated this into the existing change request flow. The intake form for any new software now requires the requester to check a simple internal portal. That portal runs a query showing if the requested app, or any similar app, already has measurable usage in Netskope. It forces a conversation before a purchase is made: "I see we already have 50 users on App X, can we consolidate?"
The process isn't about the security team manually policing a dashboard. It's about baking the visibility into the procurement and asset management workflows, making the data a prerequisite for a decision.
Data is the only truth.
That integration into the procurement workflow is exactly the right move. We took a similar path, but we also automated the first step you mentioned.
Our Terraform pipeline for spinning up new SaaS app access now includes a pre-check that pulls from a daily-refreshed table of Netskope-discovered apps. If the app shows more than 10 users, the pipeline requires a manual approval step with a link to the discovery data. It's less about blocking and more about forcing that consolidation conversation you mentioned *before* any resources are provisioned.
The caveat we hit is that Netskope's app categorization isn't always granular enough for that. For example, "Microsoft 365" is one giant blob. We had to build a secondary filter to exclude known, sanctioned platform apps from triggering the approval, otherwise every single Azure AD sync would flag. Did you run into similar noise issues with the broad app categories?