650+ apps for ~3500 users, ops wants IT to justify the chargeback — how have you tackled SaaS sprawl at this scale?
Posted by NextAdhesiveness9080@reddit | sysadmin | View on Reddit | 26 comments
Genuine ask, not selling anything.
Got roped into doing a deep dive on our SaaS landscape after operations leadership pushed back on the internal IT chargeback. We're logistics, \~3500 FTE. Head office bills each warehouse per pallet location, so bigger site = bigger IT bill. That bill has grown enough YoY that ops now wants a line-by-line justification of what they're actually paying for.
Went to IT for the breakdown. They don't really have one. Rough count of the app landscape is 650–700. Some sits properly in Entra with SSO, but a meaningful chunk is:
- Departmental tools signed up for on a corp card
- Free tiers that quietly went paid
- Apps that were "approved" years ago and nobody can confirm anyone still uses
- Stuff that's only visible because finance sees the invoice
What I've already poked at:
- Pulled SSO sign-in logs from Entra. Good for the SSO subset, useless for the rest.
- Cross-checked with finance's vendor list. Naming is inconsistent — same vendor billed under 2-3 different names depending on entity.
- Asked department heads what they actually use. Answers don't line up with the invoices.
- Looked at a few SaaS management platforms (Zylo, Torii, Productiv, BetterCloud). Not sure yet whether they're worth it at our size or if there's something better suited.
Questions for the room:
- Anyone been through this exercise? What actually worked vs what wasted time?
- How do you reconcile "what finance pays for" with "what's actually being used and by whom"?
- SaaS management platforms — worth it at this size, or do you end up still doing half of it manually?
- Anything you wish you'd known before starting this kind of cleanup?
Will update the post with what we end up doing.
Art_hur_hup@reddit
At this point juste cut everyone and wait for the mails requesting access re-opening.
Jokes appart you have a long road ahead. Most saas management tools use SSO auth scopes to identify Shadow IT. You'll also find solutions coming with their "chrome plugin" sniffing login pages and saas url, they are good to detect Saas usage but good luck enforcing the install on 3500 + devices.
At this scale I'm wondering if you shouldn't look into CASB (not my expertise but seems relevant) and only after you established a critical saas list you go on to a saas management platform and start enforcing good practices and IT hygiene.
for what it's worth :)
LeadershipOnly2229@reddit
I went through something similar and “cut everyone off” was super tempting, but the blast radius is brutal if you don’t have air cover from leadership and a clear exception path. What worked for us was flipping it: define “blessed” apps first, then slowly squeeze everything else.
I started by getting logs from the IdP, firewall, and CASB trial in parallel and built a rough top 50 SaaS list by usage and data sensitivity. Once we had that, we pushed a light policy: anything handling customer data had to go through review, everyone else could keep their toys for a while.
We used Azure App Proxy and conditional access to funnel more stuff behind SSO, then tightened OAuth consent so random tools couldn’t just hook into M365.
On the tracking side, BetterCloud and Torii were fine, but Pulse for Reddit actually helped me catch user complaints and vendor mentions early so I knew which apps were about to explode in usage before they showed up in logs.
wtf_com@reddit
Never really understood why IT owns a tool that someone else is paying for.
It’s the responsibility of the department to manage their own shit. IT is there to advise and assist if necessary but fact of the matter is that whoever approves the spend owns the app.
If IT is being told to approval the app then designate an owner. No owner no pay.
Gotta stop babying the users like their kids - they are grown ass adults.
NextAdhesiveness9080@reddit (OP)
Love this! 😂 saw many funny takes on the scream test So first steps is ownership, usage and then soft removal and see what happens
wtf_com@reddit
It’s amazingly effective if you’ve never done it before.
I was working as IT manager at an O&G company and the Operations guys refused/delayed in identifying IoT assets.
So got to the point that enough was enough and we started suspending lines that weren’t identified.
After the first couple of assets done this way the rest got identified asap.
Lifegoesonhny@reddit
Out of interest, did you get approval from someone above Ops to start suspending beforehand? I've worked in several places where the sprawl was ridiculous but by the time IT found an unexpected service it was already embedded in several "important and time saving processes" for internal and revenue making departments, so it was continued to be allowed (I'm sure it was, but shared accounts and poor security practise being a level of risk the company claimed to be actively working against).
Buy-in to do this type of approach seemed impossible, they would escalate to C-Suite at the mere mention of IT getting involved, let alone suspending access. We ended up just creating a list of 'owners' as we found them, which was never up to date and the list continued to grow; plus IT now expected to support. I'm out of these environments now, but I'm interested to hear the business side of this decision if you can share?
wtf_com@reddit
The driver was Accounting - they had made several requests to us to assist them in identifying the assets in question.
We in turn went to Operations and did the same. The request went on for a couple months without answer at which time we decided to scream test them.
The process went as follows:
We notified the Operations group that due to the lack of identifiable information we were treating these unmarked units as stole and were suspending internet access to them.
We confirmed internally that we would only suspend them and that we could reactivate them on a moment’s notice without delay.
We also identified a unit that was using the least amount of data and suspended that device first.
Once the data failure triggered in OP’s reporting tool they came to use to confirm why there was a loss of service.
We asked them to identify which device failed; marked the device correctly and restored service.
When Ops inevitably asked us cause of loss of service (after the second one went down) we forwarded over the several months long email requesting and the following notifying them of the suspension.
I did get a call from the field supervisor but once I showed him the emails he pretty much told his guys to get on it and that was pretty much it.
Lifegoesonhny@reddit
Thanks so much for the detailed answer - using a hierarchy of risk to identify some smaller targets to begin with is something I'll take forward in future roles. I really like this approach - even if we get serious pushback from the C-Suite we can demonstrate how little impact it had in reality VS the screaming.
Really appreciate the info on the steps you took, thanks again!
wtf_com@reddit
No problem at all; happy to help.
doyouvoodoo@reddit
After the scream test, policy is your friend:
There should only be one department managing software acquisition/licensing (preferably 2 people from the IT team because two is one and one is none).
Absolutely no software subscriptions should be getting paid for via company credit cards, they should instead be getting invoiced to and paid through the finance team.
Near the end of the company fiscal year, the two people that manage the software acquisition need to send out an annual check-in to each departments senior manager so they can verify if the department has a need for the software and if so, how many licenses the department needs, the senior managers then respond with the software titles and head count authorizing the purchase of "x" number of licenses at "x" dollars per software title for the next fiscal year.
VA_Network_Nerd@reddit
Sorry, it seems this comment or thread has violated a sub-reddit rule and has been removed by a moderator.
Do Not Conduct Marketing Operations Within This Community.
Your content may be better suited for our companion sub-reddit: /r/SysAdminBlogs
If you wish to appeal this action please don't hesitate to message the moderation team.
Sk1tza@reddit
We have a few (paid) tools we use for app accounting and that would give you ammo to say "this app has not ben used for x days/months" and you can make an educated decision from there but 700 app seems huge.
Niko24601@reddit
3 paths:
Manual: scream test: cut stuff and see who complains. This will feel a bit like whack-a-mole
CASB: really good at discovery. There is manual work after this
SMP: Get a good solution with decent discovery and then more important the integration capabilities to really pull in all the data and automate the maximum. Check out Gartner for the best Saas Management platforms: torii, corma, zylo, bettercloud. For 3,5k users a justifiable expense imo.
Sasataf12@reddit
How do you eat an elephant?
If you're willing to spend money, there are SaaS management tools/services out there. 1Password acquired one not too long ago. Can't remember the name.
Altruistic_One_8427@reddit
I think you mean Trelica. But from what I heard is that they basically doubled the prices after the acquisition which were already not low to start with. there are tons of tools out there and I think there are dozens of threads here where many vendors get discussed. Depending on needs, budget, requirements, integrations etc. the best saas management platform can be any of torii, corma, zluri zylo, lumo and all the others (I benchmarked them a while ago so I remember many names lol)
Lifegoesonhny@reddit
Interested to see the outcome! I have yet to see it done successfully - but I have some experience with the beginning stages with on onboarding into a SaaS management platform provided by a third-party.
TL;DR: the management platform got dropped on internal IT to implement, who did not have the resource, skills, nor time to deliver it. Quite a few months later (by the time I left) it was essentially just an IT SaaS database which didn't apply to the rest of the business.
Depending on the size, age, and structure of the organisation (including full buy-in for the whole onboarding project from C-Suite) third-party SaaS management platforms require an extreme level of business analysis, not just the tech side through access. The whole reason the shadow IT is there in the first place is a business and process problem at its core - whether approval processes are not clear or visible, not enough trained staff to process new SaaS requests (security, IT Ops, Architecture, Finance, etc.), or just plain old "get it done" mentality in other departments with no consequence (who happen to have access to a corporate credit card). As an IT bod, I wouldn't advise taking this on from what I've seen is involved in the onboarding alone. The business needs analysts who can act as a bridge between departments - IT can provide access data and other information from the systems, but they cannot be responsible for informing or building the picture of the 'why' part of this process; they were never involved in the decision making part of most SaaS applications they now find themselves supporting in these types of organisations. An IT Team cannot analyse why a Finance department purchased and embedded a new payroll application instead of using the existing one for example.
In my case, the business didn't want to spend on proper resource to undertake this work, so now the platform is more of a high-level contract database for things know to IT through helpdesk tickets that is out of date and only includes some of the landscape. It didn't seem to solve anything more than the SharePoint list we were using originally (that was imported into the SaaS Management Platform).
My only takeaway from this is if you have any clout in the org (or know someone who does), present the access data but contextualise it by explaining how much of a gap there is in understanding (let alone the missing parts of that data, which always exists). Business analysis is required for success, which IT is not positioned to do. This isn't really an IT thing to solve in my opinion and experience, I sat in several meetings pointing out the obvious flaws in the onboarding, alongside the vendor who were pointing out the same things (they were also getting frustrated) - business plowed on with it regardless...
Best of luck with it, not sure if the above insights help.
NextAdhesiveness9080@reddit (OP)
This is the clearest articulation of the failure mode I've heard. Coming back with what we end up doing.
Lifegoesonhny@reddit
Glad it was useful and makes sense :) Looking forward to hearing your results! Best of luck with the challenge, I know it's not an easy one!
Masam10@reddit
Buy a SAM tool like Snow Atlas - it will literally pay for itself and do the heavy lifting in identifying who is using software and who isn't (therefore identifying cost savings on licensed software).
It also allows charge backs, etc..
Rather than figure this all out yourself I would honestly just buy a tool.
Formal-Run-8099@reddit
Time for the good ole scream test.
Those that you know are being used, leave alone.
Those where there is less certainty on usage or ownership, disable and wait for the scream. Then you can at least have conversations with those users about them and take it from there
Signal_Till_933@reddit
I concur. The only viable ways are scream test or go back in time and create useful documentation.
doyouvoodoo@reddit
There should only be one department managing software acquisition/licensing (preferably 2 people from the IT team because two is one and one is none).
Absolutely no software subscriptions should be getting paid for via company credit cards, they should instead be getting invoiced to and paid through the finance team.
Near the end of the company fiscal year, the two people that manage the software acquisition need to send out an annual check-in to each departments senior manager so they can verify if the department has a need for the software and if so, how many licenses the department needs, they then respond with their titles and head count and authorize the purchase of "x" number of licenses at "x" dollars per software title for the next fiscal year.
gumbrilla@reddit
Poster Analysis (u/Fine-Ad9297)
The user profile shows behavior consistent with "authentic-appearing" marketing accounts: [1]
VexingRaven@reddit
Get noted, OP. Scumbag.
Valkeyere@reddit
The invoices aren't coming through from vendors as a lump sum.
If you want to work things out it isnt a quick task but starting with getting acciunts to send you a copy of all IT invoices in a year (to cover annual commit stuff) and then just parsing that till you have a list of every tool youre paying for.
Now you can go down that lost and determine who is using it, how its configured, is it needed one by one.
Only way to be sure you accurately know what youre being charged for is to start at the invoices.
And its a necessary thing too. Accounts should have being doing this to begin with, this isnt something IT is meant to maintain or generate after the fact. Thats why when you need to get licenses for stuff you go through accounts, they should have been documenting the licenses as they go up and down and what for.
VexingRaven@reddit
Honestly, I'm confused who is paying who for what and who wants who to justify which just reading your post. I'd probably start just by breaking down cost into broad categories. LoB app vs security license vs HR software license, etc. The only way you're going to make a dent in something like this is having multiple people working full time on untangling licensing, auditing app usage, etc. At the org I work for, we have an entire department within IT for purchasing and contracts, and part of that is working with app support, endpoint engineering, etc to get an accurate picture of what's needed, tidy up unused licenses, etc. What you're being asked for is not a small task, but it is a necessary one and there's no real shortcut for a lot of it. Maybe some AI tool can help these days, idk. A lot of this stuff needs to be thrown back to the business to explain why they need 650 apps for a 3500 person logistics company. How many apps can you possibly need to move pallets from A to B?