Shadow IT isn't a people problem — it's a procurement problem

Every few months, a security conference presentation or a vendor blog post will diagnose shadow IT and then prescribe employee education as the cure. Train people on policy. Remind them of the risks. Post a banner in Slack.

We’ve watched this playbook fail consistently for fifteen years, and we think it fails for a predictable reason: shadow IT is almost never a behavior problem. It’s almost always a procurement problem.

The pattern, repeated

Here is how shadow IT typically enters a regulated organization. A team has a real workflow need — securely sending a large dataset to an outside auditor, sharing design files with a client, getting a signed agreement back quickly. They check the approved tool list. The approved tools either don’t do what they need, require an IT ticket with a three-week SLA, or are so clunky that using them takes three times as long as the task itself.

So they use Dropbox, or a personal Gmail attachment, or a consumer file-sharing link, or a screenshot sent over a chat platform. Not because they’re careless. Because they’re trying to get their job done, and the friction of the approved path exceeds the friction of the unapproved one.

The security team finds out — in a log review, or a vendor assessment, or an incident — and the response is a policy reminder, a mandatory training, sometimes a corrective action. The behavior pauses for a few weeks and then resumes, because nothing about the underlying workflow changed.

Why blame-the-user campaigns don’t work

Security awareness training has genuine value in certain threat models. Phishing recognition, password hygiene, social engineering awareness — these address behaviors where the gap is knowledge. Shadow IT is different. The employees using unapproved tools typically know it’s against policy. They’re not confused. They’ve made a rational friction calculation and the approved path lost.

Training doesn’t change that calculation. It just adds guilt and, eventually, concealment. When employees know they’ll be corrected for using the wrong tool, they stop reporting it. The shadow IT doesn’t disappear — it goes further underground, making it harder to detect and remediate.

There’s also a measurement problem. Security teams often count shadow IT incidents as policy violations and track them as a training failure metric. This creates pressure to underreport rather than address the root cause. We’ve talked to CISOs who suspected their shadow IT numbers were an order of magnitude higher than what appeared in their SIEM, precisely because the tooling was treated as a compliance issue rather than a signal about workflow gaps.

Procurement-first thinking

The procurement-first framing inverts the usual approach. Instead of “how do we get employees to use the approved tool,” the question becomes: “does the approved tool actually solve the workflow at the friction level employees will accept?”

This is a product and procurement question, not a training question. It requires talking to the teams generating the shadow IT and understanding what, specifically, they’re trying to do and why the approved tool isn’t doing it. That conversation is often uncomfortable because the answer is sometimes “the approved tool is worse, and IT bought it because it checked compliance boxes, not because it serves the workflow.”

The compliance-box problem is real. Procurement evaluation criteria in large organizations are often dominated by vendor checklists — does it have SSO, does it have a BAA, does it have audit logs — without equal weight on usability and workflow fit. A tool can pass every security checklist and still be so friction-heavy that employees route around it. The security properties only matter if people actually use the tool.

Procurement-first thinking means adding workflow fit as a first-class evaluation criterion alongside security compliance. It means putting the actual end-users in the evaluation process, not just IT and security. And it means accepting that a secure tool that gets used is vastly preferable to a secure tool that doesn’t.

A practical playbook

We’ve seen several patterns work well when organizations take the procurement-first approach seriously.

Audit the shadow IT before addressing it. Before making any changes, understand specifically what tools employees are using and what workflows they’re serving. Many DLP tools and network proxies capture this data; the gap is usually that nobody looks at it through a workflow lens. What you’re looking for is not “employees are using Dropbox” but “the finance team uses Dropbox to exchange closing documents with outside counsel because the approved DRM system strips file formatting.”

Match tool selection to workflow frequency. High-frequency workflows warrant more investment in tooling than low-frequency ones. If one team sends large files to external partners forty times a week, that workflow deserves a purpose-built solution with good UX, not a bolted-on capability in a general-purpose platform that nobody finds intuitive.

Reduce procurement SLA friction. Shadow IT spikes when procurement SLAs are long. If the approved process for getting a new tool reviewed is four weeks, employees will solve urgent problems themselves. Lightweight fast-track evaluation paths for low-risk tool categories can significantly reduce the incentive to self-provision.

Create a feedback channel, not a compliance escalation. When shadow IT is discovered, the first response should be a workflow inquiry, not a policy reminder. “What were you trying to do, and why didn’t the approved tool work?” yields actionable procurement signals. A mandatory training completion doesn’t.

Track the unapproved tool list as a product gap register. Every category of shadow IT is a signal that the approved toolset has a gap. Treat that list as a product backlog for IT and procurement. When the gap gets filled, the shadow IT goes away without enforcement.

We built SEND-SECURELY.COM specifically because we saw secure file transfer consistently appearing on shadow IT lists — not because organizations didn’t care about security, but because the approved alternatives were either enterprise-only, expensive to deploy, or optimized for compliance documentation rather than actual file transfer workflows. The bet was that a tool designed for the workflow first, with security properties that hold up under scrutiny, would reduce shadow IT rather than generate more of it.