How to Raise Concerns About Shadow IT in English

Shadow IT — tools, services, or scripts adopted without going through security or procurement review — often starts with good intentions and creates real risk later. This guide gives you the English for raising the concern constructively, without sounding like you’re accusing a colleague of doing something wrong.

Naming What You’ve Noticed

Describe the observation neutrally before assigning any judgment.

• “I noticed we’re piping production data into [tool] that I don’t think has gone through a security review — can you help me understand how that got set up?”
• “It looks like a few of us have started using [service] for this workflow — has that been approved, or did it happen organically?”
• “I want to flag this, not as a criticism of anyone individually, but because I think it’s worth getting visibility on.”

Asking About the Origin

Understand why the tool was adopted before proposing to remove it.

• “What was the driver for adopting this — was there a gap in our approved tooling that made this the fastest option?”
• “How long has this been in use, and does anyone know if it was ever run past security or IT?”
• “Is this handling anything sensitive, or is it limited to non-production, low-risk data?”

Explaining the Risk

Be specific about what could go wrong rather than citing policy for its own sake.

• “My concern is less about the tool itself and more about the fact that it hasn’t been vetted for how it handles our data or who has access to it.”
• “If this tool has an incident, we currently have no visibility into it, and no plan for how we’d respond.”
• “This creates a compliance gap if we’re ever audited and can’t account for where this category of data lives.”

Proposing a Path Forward

Offer a constructive route rather than just proposing to shut things down.

• “Can we get this fast-tracked through a lightweight security review instead of blocking it outright, given how useful it’s become?”
• “If it turns out this can’t be approved, let’s find the closest approved alternative together rather than just removing it and leaving a gap.”
• “I’d like to propose we inventory what unapproved tools are actually in use across the team before deciding what to do about each one.”

Escalating If It’s Widespread

If shadow IT usage is broad or involves sensitive data, involve security or leadership directly.

• “I think this is bigger than one tool — I’d like to loop in security so we can get a full picture of what’s being used outside the approved list.”
• “Given the data involved, I don’t think this should wait for the next planning cycle — can we prioritize a review this week?”

Vocabulary Reference

Key Takeaways

• Describe the observation neutrally first — shadow IT is usually adopted out of convenience, not malice.
• Ask about the tool’s origin and what data it touches before proposing a fix.
• Frame the risk concretely, such as lack of visibility or a compliance gap, rather than citing policy alone.
• Propose a constructive path, like a fast-tracked review or finding an approved alternative, instead of just demanding removal.
• Escalate to security promptly if the tool handles sensitive data or the pattern is widespread across the team.

Navigating Nuance: Speaking Up About Shadow IT with Precision

Raising concerns about shadow IT – when developers or teams use applications and services outside of official company channels – can be tricky. It’s not simply a matter of saying “Don’t do that!” The goal isn’t to reprimand, but to mitigate risk and ensure alignment with security policies and overall strategy. For non-native English speakers, the subtleties of professional communication are often magnified. Using precise vocabulary and understanding common phrasing is crucial for conveying your concerns effectively without causing defensiveness or appearing overly critical.

A key difference lies in how you frame the conversation. Instead of accusatory statements like “You’re using an unapproved tool!” – which can immediately put someone on the defensive – focus on the impact of their actions. Consider phrasing like, “I noticed the team is utilizing [Tool Name] for [Task]. While I appreciate the efficiency gains, it’s important to confirm this aligns with our current data security protocols and compliance requirements.” Or, when reviewing a pull request introducing a new service, you could say, “This integration of [Service Name] presents an opportunity for us to explore its potential benefits. However, let’s briefly discuss how we can ensure it’s properly documented within our IT asset registry and that its usage is consistent with our established security guidelines.” Remember, demonstrating curiosity and a desire to understand why they chose the tool, before addressing any concerns, often fosters a more receptive environment.

Another useful tactic is to use “we” language – focusing on collective responsibility. Instead of saying “You should…” try “We need to ensure…” or “Let’s discuss how we can…” This shifts the focus from individual blame to shared accountability for maintaining a secure and compliant IT environment. For example, in a Slack channel discussing a new project, you might post: “Excited to see the team exploring [New Tool]! To keep things aligned with our security policies, let’s add it to our inventory list and discuss the potential implications with the Security Team.” This approach signals collaboration rather than confrontation.

Finally, don’t underestimate the power of specific requests for information. If you need clarification on how a tool is being used, ask for details like, “Could you share the documentation outlining its security features?” or “Can we schedule a brief meeting with IT to discuss integration best practices?” Providing concrete next steps demonstrates your proactive approach and helps ensure everyone is on the same page. These small shifts in wording can make a significant difference in how your message is received, particularly when working across cultures and language barriers.