What is Shadow IT?

Last Updated on February 27, 2021 by Dave Farquhar

What is Shadow IT? It’s something every IT professional comes into contact with at some point and wishes they hadn’t. Here’s what Shadow IT is, why it’s bad, and how to avoid it.

Examples of Shadow IT

Shadow IT is nothing more and nothing less than unauthorized computer systems. They are computer systems that found their way into production by some means other than normal, authorized channels.

Whenever I’m talking with a new client, invariably the topic of shadow IT comes up. Finding that rogue datacenter running on old desktop PCs sitting under Bob’s desk is part of what I do for a living.

I’m not 100% certain it was shadow IT, but I once saw an Emachine in a datacenter. That’s the most craptacular excuse for a server I’ve seen, but hardly the only one. The server I called the Legions of Doom server was the biggest close call I ever ran into. And a recommissioned 386 turned into an unexpected $1,000 Shadow IT mistake.

Why Shadow IT happens

Shadow IT happens because IT departments often don’t move fast enough for the business they support, and sometimes refuse to do the work the business needs entirely. At one of my former employers, Blackberry devices led to so much shadow IT that eventually the official IT department got overthrown. But shadow IT also happens because American society encourages it. People admire others who cut through what they see as bureaucratic nonsense and get things done quickly and cheaply.

Here’s an example from my own career. Almost 20 years ago, I was helping an underfunded department migrate from some really old, underpowered Macintoshes to then-new, business-grade Micron PCs running Windows NT. The problem was moving the data from their old computers to their new ones. Today there are lots of ways to do it, but in the days before USB, when the machines used completely different disk and network formats and even used different standards for plugging in hard drives, there weren’t a lot of options. I really needed a Windows NT server with Services for Macintosh running on it. Even that option had problems, but I knew how to hold it together long enough to get the data over. Services for Macintosh failed a lot, but it failed fairly predictably.

The Windows team refused.

So I stood up my own temporary server running Services for Macintosh, and named it Barfy. My boss helped. And my boss and I got in a lot of trouble when we got caught. You weren’t allowed to build servers unless you’d passed the Wolfe Aptitude Assessment Battery Programming test from 1968. We’d only passed the Wolfe Computer Operator Aptitude Test from 1968. This was 1999 and I wish I was joking about the tests.

And when I tell that story, there’s about a 50 percent chance you think Young Dave was a loose cannon, and about a 50 percent chance you admire Young Dave’s willingness to cut through a lot of bullcrap.

Why Shadow IT is bad

The reason we got caught with Barfy shows why Shadow IT is bad. One night, one of the Windows NT servers on this network started acting up, and our crack Windows team couldn’t figure out why. So they called in Compaq to figure it out for them. Compaq spotted Barfy on the network and rightfully got suspicious. Barfy ended up not having anything to do with the problem, but it wasted a lot of billable time, if nothing else.

But I can think of several other examples from that part of my career where shadow IT caused problems.

• An administrator needed some more ports to plug in some new web servers. So he bought a cheap consumer-grade switch and plugged his new servers into it. The switch quickly failed. We found out that night when the backups failed to run. Nobody really knows how long those servers were offline.
• An unauthorized change to a backup server stopped all backups at a site for about a week, resulting in data loss.
• A fleet of unauthorized servers showed up in a datacenter without anyone being told. The administrator expected the servers would automatically get backed up. They weren’t, and he was disappointed when something went wrong and he needed files restored on one of the servers.

Shadow IT cuts through a lot of red tape, but when something inevitably goes wrong, it often results in data loss, production outages, lost productivity, and needless expense.

Shadow IT is a security issue

You can’t defend a system you don’t know about. Standard security practices like centralized logging, uptime monitoring, patch management, and backups usually don’t happen unless someone sets them up. If someone sets them up improperly, they may not work. And then that system is less reliable than it could be, but it also turns into a weak point in your network where a hacker can establish a beachhead on your network. Unauthorized software can introduce hundreds or thousands of vulnerabilities into a network.

What to do instead of shadow IT

A critical component of good IT is a change control board or change advisory board. This group of people meet on a periodic basis to discuss changes to IT systems and approve and document them. In some companies, these meetings happen every day. In smaller environments, they might only happen once a month.

But the meeting ensures that all stakeholders are aware of changes that might affect their systems. That way, if something goes wrong, there’s one place to look for every change that occurred since the problem happened. It’s possible, or even likely, that the problem was anticipated and the corrective action is documented. But if it isn’t, administrators can unwind changes until they find the change that caused the problem. This minimizes the downtime.

There’s another side effect to talking about changes and documenting them in advance of doing them. The process of doing those two things often turns up problems before they happen, and allow the administrators to improve their work. This makes something less likely to go wrong in the first place.

Going through a CAB or CCB process can be painful. It consumes a lot of time, and it does seem like a disproportionate number of cranky old dudes participate in the process.

But the two longest stops in my career were polar opposites of one another. One of those stops had tons of problems with systems breaking in the middle of the night, and the rest of the business hated the IT department. The second stop had five-nines uptime, in spite of its administrators having less education, less experience, and in many cases using cheaper, lower-tier hardware.

The biggest difference between those two shops was the presence of a change control board. Shadow IT didn’t exist there. It meant we could do more with less, and we never got dragged into a meeting where the topic was “working smart.” When everything is documented and authorized, there’s no need to talk about working smart. Working smart is just part of the process.

The book The Phoenix Project by Gene Kim deals with Shadow IT, and many of the issues that lead to it.

What do you do with shadow IT when you find it?

Some places look the other way when it comes to shadow IT. The problem with this approach is that ignoring it tends to legitimize or reward it, and shadow IT eventually becomes a cancer within your environment.

Other places take the other extreme. If it’s not legitimate and approved, you unplug it, immediately and without question. Some shops even buy weird-colored network cables and keep them locked up. If a system shows up with a standard blue or yellow network cable plugged into it, it sticks out, and that system will end up in the hallway pretty quickly.

Most shops take a more middle-of-the-road approach. If you built it, own up to it and bring it into the system legitimately. Get the approvals and correct any subpar practices that went into building it.

What is shadow IT and how do I avoid it?

So hopefully I’ve convinced you why shadow IT is bad. When IT resembles the wild west, the result is chaos, lost productivity, system outages, and unnecessary expense.

The way you avoid shadow IT is by establishing system governance, with an approval process. As long as key stakeholders meet on a regular basis to discuss all proposed changes and approve them and document them in one place, and the stakeholders make sure IT doesn’t get in the way of the business making money, most of the other details don’t matter very much.