The Cookie Incident

I remember visiting a client just before the Christmas break. Central IT was joining the meeting, and I'd brought along some festive baked goods to share.

As I placed a Rudolph's Red Velvet Crinkle on the desk in front of the Head of IT, he didn't smile. He looked at it sternly, then at me, and said: "I'm going to have to declare this."

Which rather set the tone for what followed.

I'm not telling this story to mock IT. That response - instinctive, cautious, by-the-book - exists for a reason. IT teams have spent years cleaning up messes created by well-intentioned people who didn't think through the consequences. They've seen "quick pilots" become permanent infrastructure. They've inherited contracts signed by departments who didn't read the data-processing clauses.

The wariness is earned.

But earned wariness doesn't always translate into effective protection. Too often, the mechanisms designed to manage risk end up creating a different kind of risk entirely.

When the default posture is defensive, departments stop asking. They find workarounds. They spin up their own cloud instances, sign their own vendor contracts, deploy tools without oversight. The sector has a name for it: shadow IT.

And shadow IT isn't just a compliance problem. It tells you where official processes are failing the people trying to move fast.

Beyond the Checkbox: The Illusion of Compliance

When a department identifies a new tool they want to use, the first hurdle is almost always the standard procurement questionnaire. These forms are filled with predictable, high-level technical queries: Is your data encrypted at rest? Is the platform SOC 2 certified? Is the data hosted within the UK or EU?

The vendor, eager to close the deal, inevitably answers "Yes" to everything.

From an IT perspective, this process is the digital equivalent ticking "no" to the "Are you a terrorist?" question on an airline travel form. A necessary administrative requirement, but one that provides almost no real insight into the vendor's reliability.

The fundamental problem is that a checkbox can confirm compliance with a policy, but it cannot confirm competence in a product. To truly vet a partner, we have to move past the binary "yes/no" forms and start asking questions that reveal the operational reality of the tool.

The Questions That Actually Matter

Here's what IT teams really want to know, and what Departments should be asking on their behalf:

1. What's the expertise behind this?

Shiny new platforms come and go. What matters is whether the people building and supporting the tool actually understand the problem space. A decade of hands-on experience in your sector often counts for more than a logo wall of enterprise clients. Ask: who's behind this, and have they done this work before?

2. What happens if it doesn't work out?

Relationships end. Priorities shift. The mature question isn't "will this last forever?" but "how easy is it to leave?" Can you export your data cleanly? Is there lock-in by design or flexibility by default? IT respects vendors who've thought about their clients' exit as carefully as their onboarding.

3. What's the maintenance burden?

"No" is often code for "I don't have the staff to fix this when it breaks." Every new tool is a potential burden on the central helpdesk. The better questions: how much of this can the department own? Can department admins reset passwords, manage users, and troubleshoot common issues themselves? Is it built to be self-sufficient, or will it quietly become IT's problem?

4. Who owns the data, really?

The GDPR checkbox says one thing. The Terms of Service sometimes say another. If we leave, do we get everything back? Are there sub-processors? Can our data be used to train models or improve products we haven't agreed to?

5. What's the security culture, not just the compliance?

Certifications expire. Audits are point-in-time. The better signal: how does this vendor handle problems? Will they tell you when something goes wrong, or will you find out from your students first?

Trust is built in how problems are handled, not how brochures are written.

From Gatekeeper to Guide

The institutions making this work aren't the ones where IT has "loosened up." They're the ones where IT has been repositioned, from the department of 'No' to the department of 'Know.'

What does that look like?

Fast lanes for low-risk tools. Not every decision needs a six-month review. Tiered approval processes let departments adopt pre-vetted tools with minimal friction, reserving scrutiny for platforms that touch sensitive data or core systems.

Earlier conversations. Instead of IT reviewing a vendor after a department has already fallen in love, bring them in early when they can shape requirements rather than just block outcomes.

Shared risk language. The conversation shifts from "Is this allowed?" to "What's the risk profile, and who owns it?" When departments understand they're accepting risk, not just circumventing bureaucracy, they make better choices.

The Real Win

The goal isn't to eliminate departmental autonomy. It's to make working with IT the path of least resistance.

When IT becomes the team that helps you move faster, because they understand your needs, because they've built systems designed for speed and safety, shadow IT starts to disappear.

If you want IT to say "yes," stop bringing them problems wrapped in tinsel. Bring them guardrails wrapped in data, and answers to the questions they've stopped asking out loud.

Share this article: LinkedIn | Email