Ask any owner where their company's real operational data lives, and they will point you to the ERP, the CRM, or whatever system they paid for. Ask the staff who actually run daily operations, and half the time they will point you to a spreadsheet on someone's personal laptop that nobody in leadership has ever seen. That gap is where shadow it risks live, and in my experience it exists in nearly every SME I have audited, without exception.
Shadow IT gets talked about as a security failure, staff going rogue, ignoring policy, doing something they shouldn't. I think that framing is mostly wrong and unhelpful. The spreadsheets and personal apps I find during an audit are almost always evidence of an unmet need, not staff misbehavior. Someone built a workaround because the official system could not do what their job actually required, and nobody higher up ever noticed or asked why.
Understanding that distinction changes how you respond to it, and it is the difference between an audit that fixes something and one that just scares people into hiding their workarounds better.
Why the Spreadsheets Exist
Every shadow spreadsheet I have ever found had a reason behind it that made complete sense from the position of the person who built it:
- The official system did not support a field the business actually needed, so someone tracked it separately.
- Getting a report out of the official system took a support ticket and a three-day wait, so someone built a faster personal version.
- The approved software could not talk to a supplier's system, so someone manually bridged the gap.
- A manager left, and their replacement inherited an undocumented process with no system of record, so they built their own.
None of this is malicious. It is initiative, applied to a gap that leadership either did not see or did not prioritize fixing. The staff member who built the spreadsheet is usually the most capable person on the team, not the least disciplined.
What Shadow IT Actually Threatens
The risk is real even if the intent is not. Three failure modes show up repeatedly:
- Single point of failure. If the one person who understands the spreadsheet's formulas and macros leaves or gets sick, the process it supports simply stops working, and often nobody else knows it existed until it breaks.
- Data integrity drift. A spreadsheet that started as a simple tracker accumulates manual overrides, copy-paste errors, and undocumented logic over years. Nobody can say with confidence whether the numbers in it are still correct.
- Invisible dependency. Leadership makes decisions assuming the official system is the source of truth, while the actual operational reality lives in a file nobody official knows exists. Decisions get made on stale or incomplete data without anyone realizing it.
I saw this play out at a multifinance company where loan disbursement tracking officially lived in their core system, but the operations team had quietly built a parallel spreadsheet to handle exceptions the core system could not process. When an audit finally surfaced it, nobody, including the operations lead, could confirm whether the two systems agreed with each other for the prior twelve months. That reconciliation took weeks and delayed a compliance review.
How to Find Them
The direct question, "do you use any unofficial spreadsheets," rarely works. Staff have learned that answering honestly sometimes gets them in trouble, so they undersell what they actually rely on. A better question:
"If your laptop died tomorrow with no backup, what would stop working?"
This reframes the conversation around business continuity rather than compliance, and people answer it far more honestly. Ask it of every team lead and you will usually surface most of the shadow systems within a single round of interviews. Follow up by asking what the spreadsheet does that the official system cannot, that answer tells you exactly what gap it is filling.
Responding Without Punishing Initiative
Once you have the inventory, sort every shadow system into one of three buckets:
| Category | Response |
|---|---|
| Genuinely useful, low risk | Formalize it: document it, back it up, name a backup owner |
| Genuinely useful, high risk | Migrate the logic into a proper system, with the original builder involved in the design |
| Redundant or dangerous | Retire it, but only after confirming what replaces the gap it was filling |
The mistake I see most often is skipping straight to "ban all unofficial spreadsheets" without doing this triage first. That just pushes the workaround underground again, usually onto someone's phone or personal cloud drive, which is a worse outcome than the one you started with.
The Practical Takeaway
Shadow it risks are not a staff discipline problem, they are a signal that your official systems have gaps your team quietly filled on their own initiative. Find them by asking what would break if a laptop died, not by demanding confessions. Then formalize the useful ones and replace the dangerous ones, involving the people who built them rather than overriding them. If the root cause is that your core systems and websites were never designed around how work actually happens, the one page digital strategy every SME can write is a good next step, and for the AI angle on tightening operations around real workflows, see what AI-native operations actually means for a business.