“Shadow IT in Project Teams: Risks and How to Handle It”

What counts as shadow IT in a project team?

Shadow IT is any application, service, extension, or automation a team uses for project work that the organization has not reviewed and does not manage. Review matters as much as approval: a tool can be “allowed” on paper and still be shadow IT if nobody governs who has access, what data enters it, and when accounts are removed.

Project teams generate four common varieties:

• Unapproved SaaS. A free-tier board, form builder, recorder, or diagramming tool someone signed up for with a work email.
• Personal accounts used for work. Client files in a personal cloud drive, a personal calendar holding the delivery schedule, or a personal AI subscription summarizing meeting notes.
• Unmanaged integrations. A Zapier or Make scenario moving task data between two approved systems, built by an enthusiastic coordinator and known to nobody in IT.
• Sanctioned-but-ungoverned tools. The platform is approved, but teams spin up workspaces with open guest links and no owner: the same exposure with a better logo.

The distinction between shadow IT and “someone used a spreadsheet” is whether the tool becomes part of the delivery record or the data path. A scratch spreadsheet for a one-hour estimate is harmless. A spreadsheet that becomes the client-facing status report is a system of record nobody backs up, audits, or secures.

Why do project teams adopt shadow tools?

Teams adopt shadow tools when using the approved option costs more time than going around it. The cost is usually time, not money: the approved tool lacks a capability, procurement is slow, or collaboration crosses organizational boundaries where guest access is painful.

Gartner predicts that by 2027, 75% of employees will acquire, modify, or create technology outside IT’s visibility, up from 41% in 2022, and estimates that shadow IT accounts for 30% to 40% of IT spending in large enterprises. That describes problem-solving, not malice.

Five drivers show up repeatedly:

1. A genuine capability gap. The approved suite has no offline inspection form, client-friendly review link, or way to annotate a drawing on a tablet.
2. Procurement latency. A two-week security review is reasonable for a finance system and absurd for a $12 whiteboard needed for a two-week workshop.
3. Cross-boundary collaboration. Contractors, agencies, and clients often cannot be added to the internal tenant without a ticket and a license, so the team shares a link anyone can open.
4. Deadline pressure. When the choice is “use the free tool tonight” or “slip the milestone”, most teams choose the milestone.
5. New categories arriving faster than policy. A 2025 IBM study found that one in five organizations reported a breach involving shadow AI, and that high shadow AI use was associated with breach costs $670,000 higher than low or no use.

> Important note: A shadow tool that persists for more than a month is no longer a workaround. It is an unmanaged production system with users, data, and dependencies. Treat it accordingly.

What are the real risks?

The real risks sit in data and continuity, not in the tool’s brand. An unapproved whiteboard holding workshop stickies is a hygiene issue; an unapproved tool holding client personal data is an incident.

Triage with one question: what is the most sensitive data this tool touches, and who can reach it? Public copy behind a link is a hygiene issue. Client payroll data exposed to a vendor’s whole user base is an incident.

How much shadow IT does a typical team actually have?

Most organizations have more than their asset register shows, and the gap surfaces through four sources rather than interrogation. Start with single sign-on logs, reconcile corporate card and expense data, review network or DNS traffic for work-related domains, then ask teams a short, blameless question: “Which tools do you use that are not on the approved list?”

A worked example makes the scale concrete. A 120-person professional services firm reviewed six months of card statements and found 23 recurring SaaS charges. Nine were not approved: two whiteboard tools, two form builders, a transcription service, a screenshot annotator, a scheduling link tool, a stock-photo subscription, and an AI assistant. The run rate was $1,230 per month, or $14,760 per year. Four of the nine duplicated capability already paid for. Two held client data under a contract that required prior written approval.

The dollar figure was not the main finding. Nobody could say who owned six of the nine accounts, so nobody would close them when the project ended — the risk that survives after the subscription is cancelled.

Track five measures quarterly: unowned SaaS spend, unapproved tools holding client data, median approval time, active accounts of people who left the project, and duplicate tools per capability category.

The last one is the most actionable. Most shadow IT is not a new category; it is the fourth whiteboard.

Should you ban it, adopt it, or replace it?

The right response is usually three decisions applied per tool, not one policy applied to everything. Adopt the tool if it fills a real gap and passes a light security review. Replace it if the approved stack can close the gap with configuration, training, or a paid add-on. Retire it if it holds sensitive data, has no owner, or duplicates something you already pay for.

Two design choices make this work.

First, run a 30-day amnesty window. Teams can declare tools without punishment, and declared tools get a decision within five working days. Amnesty converts hidden risk into a list you can act on; punishment converts a list into a rumor.

Second, publish the decision criteria, not just the outcome. Teams accept “no, because this would store client contact data outside our region” far more readily than “no, because IT said so”. Criteria also let a team self-screen before signing up, which is the only scalable control.

How do you build governance that teams will actually follow?

Lightweight governance beats comprehensive governance nobody reads. The minimum viable model has five components: an approved list by data class, a fast exception path, a named owner per tool, a quarterly review, and an offboarding check that fires when a project closes.

The exception path is load-bearing. If a team can request a tool on Monday and get an answer by Friday, most of the incentive to hide disappears; if the answer takes six weeks, the policy is a tax on honesty.

A 40-person agency cut its average approval from 34 days and three signatures to one form, one reviewer, and a five-day service level. In the next quarter, declared tools rose (people finally had a reason to declare) while unowned accounts fell. The lesson: good governance increases the number of tools you know about. That is a success metric, not a failure.

What about shadow AI specifically?

Shadow AI deserves its own paragraph because the data path is different. A task board holds structured records you can export and delete. A chatbot holds whatever someone typed, and you cannot retrieve it, verify where it was stored, or guarantee it will not appear in a future model’s behavior.

The 2025 IBM Cost of a Data Breach report found that among organizations with security incidents involving shadow AI, 65% had personally identifiable information compromised, compared with 53% across all breaches. It also found that only 37% of organizations had policies to manage AI or detect shadow AI. The exposure is real, and policy coverage is thin.

A practical rule set for project teams:

• Name the approved assistant. If none exists, that is the gap to close, not a reason to write a longer prohibition.
• Apply the paste test. If the text could not be posted in a public forum, it does not go into a consumer chatbot.
• Log the use case, not the person. Track which workflows use AI so you can review the data path without surveilling individuals.

When is banning the right call?

Banning fits when data is regulated, a contract prohibits the tool, or the exposure cannot be mitigated. In those cases, enforcement needs detection, a compliant alternative, and a consequence applied consistently.

It is the wrong call when the need is legitimate and the approved stack does not meet it. A ban then removes your visibility, not the need, and the team keeps the tool while no longer mentioning it. Test any ban with one question: can the team do this work with an approved tool in the same time? If not, the ban will fail unless you also fix the tool or accept slower delivery.

What does consolidation actually save?

Consolidation saves money, but payback usually comes from reduced admin and risk, not licence fees alone. Model migration effort and the productivity dip.

A delivery team pays $620 per month for a project platform, $240 for a separate whiteboard, and $95 for a forms tool: $955 per month, or $11,460 per year. Consolidating onto the platform’s included whiteboard and forms removes $335 per month, or $4,020 per year. Migration takes 60 hours of an operations specialist at a loaded $65 per hour, or $3,900, plus $1,200 for training and template rebuilding. One-time cost: $5,100. Payback is 15.2 months on licence savings alone.

If consolidation also removes two admin hours per week at the same rate, that is $6,760 per year in recovered time, and payback falls to about 4.8 months. The point is not the specific numbers: the business case rarely survives on licence savings alone. Include admin time, renewal risk, and the reduced number of places where client data can leak.

What mistakes make shadow IT worse?

• Treating discovery as a disciplinary process. The first question after finding a tool should be “what were you trying to do?”, not “who approved this?”
• Publishing a policy with no exception path. A list of forbidden tools without a route to a new one is an incentive to use personal accounts.
• Buying an enterprise tool nobody asked for. Adoption fails, the team keeps the old workaround, and now you pay for both.
• Ignoring the contractor and client edge. Most data exposure sits at the boundary of the organization, where onboarding and offboarding are weakest.
• Measuring only spend. A free tool holding regulated data has zero licence cost and maximum risk.
• Assuming SSO solves everything. SSO covers what is integrated, not the personal card and the browser extension.

How does a single workspace reduce the incentive?

Most shadow tools exist because the official system does not cover one step of the workflow. When tasks, sub-tasks, checklists, files, meeting notes, and progress reporting live in one place, the number of steps that need a side tool drops. That is the practical argument for consolidation: fewer gaps mean fewer workarounds.

Doitify is built around that idea, with Kanban boards, multi-level tasks and checklists, dependencies, sprints, Gantt and calendar views, workload and resource management, project documents, meeting notes, risks, milestones, reporting, automations, and team chat in one workspace. It is a product we build, so treat that as disclosure rather than an independent review: for a team with a narrow need and a working stack, a smaller dedicated tool may be the better choice, and the governance advice above still applies to us.

The test is simple. Ask the team which steps of their week happen outside the platform. If the list is long, the platform is producing shadow IT, whether or not anyone has signed up for anything yet.

Conclusion

Shadow IT is a signal about your delivery system, not a verdict on your team’s discipline. The team found a gap between the work and the tools, and closed it because the official route was slower than the deadline.

Handle it in three moves. Make the invisible visible with logs, spend data, and a blameless survey. Triage each tool by the data it touches, then adopt, replace, or retire it. Build an exception path faster than hiding. Then the next tool your team needs arrives as a request instead of a discovery.

If this post on shadow IT was helpful, you might also enjoy Why Teams Keep Missing Deadlines (Real Reasons) and Project Management Life Cycle: The 5 Phases Explained.