When people hear "shadow IT," they usually think of a marketing manager signing up for an unapproved SaaS tool with a corporate credit card. That was the shadow IT of 2018. The version we deal with now is bigger, harder to detect, and carries far more risk - especially in regulated industries.
I'm talking about entire cloud environments spun up outside of IT governance. Data engineers building pipelines on personal AWS accounts because the approved request process takes six weeks. Teams adopting AI coding assistants that send proprietary code to third-party APIs. Analysts running patient data through LLMs to generate summaries, because nobody told them they couldn't. Each of these seems harmless in isolation. In a regulated environment, any one of them can trigger a compliance incident that costs millions.
Shadow IT Has Evolved
The old model of shadow IT was relatively contained. Someone buys Trello instead of using Jira. Annoying from a governance perspective, but the blast radius is small. The data involved is usually low-sensitivity project tracking information. You find it, you migrate it, you move on.
The new model is different in kind, not just degree. Cloud infrastructure is self-service by design. A developer with a credit card can provision a production-grade environment in minutes. AI tools are everywhere, and most of them involve sending data to external endpoints. Data pipelines can move regulated information across jurisdictions before anyone in compliance knows it happened.
In healthcare, that means PHI flowing through systems that aren't covered by your BAA. In financial services, it means trading data sitting in an environment that hasn't passed SOC 2 review. In government contracting, it means CUI stored on infrastructure that doesn't meet FedRAMP requirements. These aren't theoretical risks. I've seen variations of all three in customer conversations at Citrix.
DaaS Was Supposed to Fix This
Desktop-as-a-Service and VDI were built, in part, to address exactly this problem. Centralize compute. Keep data in the data center. Give users a virtual desktop where everything is managed, monitored, and compliant. On paper, it works perfectly. Data never leaves the controlled environment. Users get access to what they need without IT losing visibility.
In practice, users are creative. They screenshot sensitive data from their virtual desktop and paste it into a local ChatGPT window. They download reports to their local machine "just to review on the plane." They use personal devices to access cloud tools that replicate functionality already available in the VDI environment, because the VDI version is slower or clunkier or missing a feature they want.
DaaS is still one of the best tools we have for centralizing control in regulated environments. But it's not a complete solution by itself. If the governed path is harder to use than the ungoverned path, people will find workarounds. They're not being malicious. They're being productive. The system is the problem, not the user.
Governance That Doesn't Create Friction
This is where the TPM role becomes critical. The natural instinct from security and compliance teams is to lock things down. Block all AI tools. Restrict cloud access. Add more approval gates. I understand the impulse, but I've watched it fail repeatedly. Heavy-handed restrictions don't eliminate shadow IT - they drive it deeper underground, where it's even harder to detect.
The TPM's job is to design governance that works with how people actually operate, not against it. Guardrails, not gates. That means a few things in practice:
Build an approved service catalog that's actually good. If your team needs an AI assistant, give them one that's been vetted and runs within your compliance boundary. If they need a data pipeline tool, have an approved option ready that they can provision in hours, not weeks. The catalog has to be maintained and updated regularly. If it's stale and missing tools people actually need, they'll go around it.
Make the request process lightweight. I've seen organizations where getting a new cloud service approved requires a 40-page security questionnaire, three committee reviews, and a six-week timeline. That process exists because someone wanted to be thorough. What it actually produces is shadow IT, because no team with a deadline is going to wait six weeks. A tiered review process works better - low-risk tools get a fast-track review measured in days, not weeks. High-risk tools involving regulated data get the full treatment. Match the process to the actual risk level.
Run periodic discovery audits. Not as a punishment mechanism - as a health check. Use cloud access security brokers to identify unapproved SaaS usage. Review cloud billing accounts for environments that aren't in your asset inventory. Check network logs for data flowing to unexpected external endpoints. When you find shadow IT, the first response should be "how do we bring this into governance" rather than "who do we blame." If you make audits punitive, people get better at hiding things. If you make them collaborative, people start self-reporting.
Make the Right Path the Easy Path
The principle I keep coming back to is simple: if the compliant way of doing something is also the easiest way, you won't have a shadow IT problem. People don't seek out ungoverned tools because they enjoy risk. They do it because the governed tools are too slow, too limited, or too painful to access.
At Citrix, we think about this constantly in how we design DaaS experiences. If the virtual desktop is fast, well-provisioned, and has the tools people need pre-installed, there's no incentive to work around it. If it's laggy and missing key applications, people will find alternatives. The technology isn't the hard part. The hard part is keeping the experience good enough that users don't feel the need to look elsewhere.
For TPMs managing governance programs, this means your job extends beyond writing policies. You need to track user experience metrics alongside compliance metrics. Are request turnaround times actually meeting SLAs? Are teams using the approved catalog or going around it? When teams go around it, what's the reason? If 60% of shadow IT incidents trace back to "the approved tool didn't support what I needed," that's a catalog problem, not a people problem.
In regulated industries, the stakes are too high for governance to be an afterthought. But they're also too high for governance to be so burdensome that it drives behavior underground. The organizations that get this right treat compliance infrastructure as a product - something that needs to be usable, maintained, and continuously improved based on how people actually work. That's not just a security initiative. It's a program management challenge, and it's one of the most impactful things a TPM can own.