Somebody in operations needed to send a large file, so they created an account with a file-sharing service. Somebody in sales wanted scheduling links, so they signed up for one. Somebody in finance built an automation between two systems because doing it by hand was taking an hour a week.
None of them did anything wrong. Each solved a real problem quickly using their own initiative, which is the behaviour most businesses say they want.
The result is that customer data now sits in at least two systems you have no contract with, three subscriptions renew monthly against a card nobody reconciles, and one important process depends on an automation that exactly one person understands.
Start by getting the framing right
The instinct is to treat this as a discipline problem. That framing guarantees failure, for a simple reason: it destroys the information you need.
Shadow IT starts with somebody trying to do their job. The approved tool was slow, or did not do the thing, or required an approval that takes three weeks. So they found something that worked in ten minutes.
Read that as a signal rather than misconduct. Every shadow tool is a small piece of evidence about where your sanctioned options are too slow or missing entirely, and that evidence is more valuable than the tidiness you would gain by banning it.
Banning also does not work. People who need a tool to do their job will find one. What a ban changes is whether they tell you, and once disclosure stops it does not restart. You end up with the same tools, less visible.
Knowing what you have is the foundational control
This is not a soft governance concern. It is the first thing established security frameworks ask for.
The CIS Critical Security Controls put inventory and control of enterprise assets first, and inventory and control of software assets second [1][2]. They come before patching, before access control, before anything else, on the straightforward reasoning that you cannot protect, patch, or decommission something you do not know exists.
The software control asks organisations to actively manage all software so that only authorised software is installed and can run, and so that unauthorised or unmanaged software is found and prevented from installing or executing [2]. That is the full enterprise version and it is more than most small businesses need. The transferable principle is simpler: keep a list, and have a defined position on anything not on it.
Two further details from the same control are worth borrowing directly.
On unsupported software, the guidance is that only currently supported software should be designated as authorised. Where something unsupported is genuinely necessary, document an exception recording the mitigating controls and the accepted residual risk. Anything unsupported without that documented exception is treated as unauthorised [2]. Most businesses have never applied that test to anything.
On unauthorised assets, the asset control specifies a defined process for addressing them, with options to remove from the network, deny remote connection, or quarantine [1]. The enterprise cadence is weekly, which is more than a small business needs. The point that transfers is that there should be a defined response rather than an ad hoc reaction when somebody happens to notice something.
What it actually costs, in four ways
Worth separating, because "shadow IT is risky" is too vague to act on and the four costs need different responses.
Money you are paying twice. Two departments subscribed to tools that do the same job, both unaware of the other. Seats still billing for people who left eighteen months ago. Annual plans renewing automatically for tools nobody has opened since a project ended. This is the easiest to find and the easiest to recover, and it is usually the smallest of the four.
Data in places you cannot describe. A client asks where their information is stored. A regulator asks what personal data you process and where. If the honest answer involves a tool you did not know about, hosted somewhere you cannot name, under terms nobody read, you have a problem that money does not fix.
Access that outlives employment. The person who created the account personally still has it. Nothing in your leaver process touched it, because nothing in your leaver process knew about it. This is quiet, ongoing, and the one most likely to become a genuine incident.
Fragility nobody can see. The automation between two systems that one person built. It runs silently, it has no documentation, and when it stops, the first symptom is something downstream being subtly wrong rather than an alert. Nobody notices for weeks.
Rank your findings against those four rather than treating the list as uniform. The instinct is to start with the spend, because it is concrete and satisfying to fix. The second and third categories are where the actual exposure sits.
Finding it, without any tooling
Start with the money, not the network.
Export twelve months of company card statements and supplier payments. Look for recurring charges you do not recognise, and pay particular attention to small monthly amounts in foreign currency, which is what most software subscriptions look like on a statement.
That single exercise finds most of what exists, takes an afternoon, and requires nothing technical.
Then find the things money will not show you.
Free tiers. These never appear in any financial record, and they frequently hold the same data as the paid ones. Free means harder to find, not safer.
Third-party app access. Check which external applications have been granted access to your main email and file storage accounts. That list takes minutes to review and is often the most revealing thing in the whole exercise.
Ask people. Directly, framed as a request for help rather than an audit.
That framing has to be genuine. Say plainly that nobody is in trouble and that the goal is to make useful tools official rather than remove them. Then hold to it, because the first time somebody is criticised for an honest answer, disclosure ends permanently.
A good question to lead with: what do you use that the approved tools cannot do? It gets you the inventory and the diagnosis at the same time.
The conversation that gets you the truth
The inventory exercise succeeds or fails on one conversation, so it is worth being deliberate about how it runs.
Do not open with a list of things you have found. That immediately makes it an audit, whatever you say afterwards, and people will answer defensively and minimally.
Open with the diagnosis instead: what do you use that the approved tools cannot do? That question invites people to explain a problem rather than confess a purchase, and the answer contains the inventory anyway. Somebody describing why they use a particular scheduling tool has just told you they use it.
Follow with two more. What would slow down if we took it away? And who else on the team relies on it? The first gets you the genuine value, which prevents you removing something important on tidiness grounds. The second surfaces the tools that have quietly become infrastructure while nobody was watching.
Then hold to what you promised. If somebody names a tool and the response is a lecture about procurement, you have bought a single data point at the cost of every future one. That trade is always bad and it is not recoverable, because word travels faster within a team than any policy does.
The businesses that get a genuinely complete picture are the ones where telling the truth about this has visibly worked out well for somebody, at least once, in a way other people saw.
Three outcomes, and most things land in the first
Sort what you find into three groups.
Adopt it properly. Move billing to the business, put ownership in the business's name rather than an individual's, record who has access, confirm the export path works, and give it a named internal owner. Our guide on the accounts your business must own covers the ownership question, which is the part most commonly left sitting in somebody's personal email address.
Replace it with something already approved that does the same job, where one genuinely exists and is not worse.
Stop using it, with a plan for the data inside it first. Our guide on getting your data out covers testing an export before you rely on being able to do it.
Most items land in the first group, which usually surprises people who approached the exercise expecting to run a purge.
Deal with these first
Not everything on the list carries the same weight.
Data you cannot account for is the top priority by a distance. Duplicate spend is annoying and recoverable. An unpatched tool is a manageable risk. Customer records sitting in a system you have no contract with, cannot export from, and could not describe to a client or a regulator is a genuinely different category. Establish what is in there, where it is hosted, who can see it, and whether you can get it out. Where personal data is involved, obligations under UAE data protection law apply regardless of whether anybody approved the tool, and the specifics belong with a qualified adviser. Our guide on PDPL compliance covers the general obligations.
Accounts belonging to people who have left is usually the most urgent operational finding and often the largest. An account a departed employee created personally may still be active, still billing, still holding data, and still accessible to them. Add one question to your leaver process, asked while the person is still there to answer it: what tools did you set up?
Single-person dependencies. Automations connecting systems together are the common case and the most fragile, because they run silently and nobody notices they have stopped until something downstream is wrong. Establish what each one does and who else could run it.
Make the approved route faster than the unapproved one
This is the whole prevention strategy, and everything else is detail.
If getting a tool approved takes three weeks and a form, people will keep going around it, and they will be right to. If a request gets a decision in two days, almost all of the incentive to hide anything disappears.
A workable process is short. One form asking what it does, what data goes into it, what it costs, and who else could use it. A named person who responds within two working days. And a default answer of yes for low-risk tools handling no customer data.
Put the decision with somebody senior enough to say yes quickly. That matters more than technical expertise for the great majority of requests. The common failure is routing everything to a busy technical person, which recreates exactly the delay that caused the problem in the first place. Escalate the small number of genuinely risky cases rather than sending everything down the slowest path.
Keep a list that stays roughly true
Seven columns in a spreadsheet is entirely adequate: the tool, what it is for, who owns it internally, what it costs, what data it holds, who has access, and when it was last reviewed.
Review it quarterly, and attach that review to something that already happens, such as a finance review, so it does not depend on anybody remembering. An inventory nobody revisits is wrong within months and then abandoned, which is worse than never starting because it creates false confidence.
One note on figures: you will see claims about how much duplicate software spend the average business carries. We are not repeating any of them, because the ones in circulation come from vendors selling software-spend management. Check your own, which is a better number anyway. Look for two teams paying for tools that do the same job, and for seats still billing for people who left.
Two things worth a specific question
AI tools. The pattern is identical to any other shadow tool, with one addition: what happens to what gets pasted into it. Ask what your team is using and what they put into it, then decide a position and communicate it. In the absence of a stated position, people reasonably assume it is fine.
Managed IT providers. If you have one, ask what visibility they actually have rather than assuming this is covered. A managed provider sees devices and networks. It generally cannot see a subscription somebody bought on a personal card and expensed, or a free account created with a work email address.
This week
Export twelve months of card and supplier payments, and highlight every recurring charge you cannot immediately explain, especially the small ones. Then ask two teams what they use that is not on the list you just built.
An afternoon, and it will surface most of what exists.
Resist turning it into a project. A rough list produced this month is considerably more useful than a comprehensive one that never gets finished.
If you want help, building the inventory, assessing what is genuinely risky, checking export paths and setting up a lightweight approval route starts from around AED 1,500 with us. Where it extends to migrating data out of tools you are retiring, that is a defined piece of work priced separately. Final pricing depends on scope, and these are our own figures rather than a market survey.
References
- CIS Critical Security Control 1, inventory and control of enterprise assets
- CIS Critical Security Control 2, inventory and control of software assets
- CIS, the 18 critical security controls
- SKIMBOX, the accounts your business must own
- SKIMBOX, getting your data out
- SKIMBOX, PDPL compliance in the UAE
- SKIMBOX, cybersecurity for small business in the UAE
The CIS Controls are written for organisations of varying size and their full implementation targets enterprise environments. They are cited here for the underlying principle and the specific definitions quoted, adapted in this article to what is proportionate for a smaller business. This is not legal advice.
