Most third-party risk management programs carry a quiet assumption: a vendor only becomes a vendor once procurement knows about it. That assumption is the blind spot itself. Every unsanctioned SaaS tool an employee signs up for with a work email is, functionally, a third party holding company data. It simply never entered the process built to assess it. Treating this as a policy-enforcement problem misses the point.

In my experience, banning unauthorized software has never eliminated it; it has only pushed the practice further from visibility. The more useful question isn’t how to stop shadow IT from happening, but how to bring it back inside a risk assessment process it currently bypasses entirely.

Why Your TPRM Program Doesn’t See It

Third-party risk programs are built to intercept vendors at a specific point: the moment someone requests a contract, a purchase order, or procurement approval. That works well for vendors who come through the front door, but it does nothing for a marketing coordinator who signs up for a free trial with a corporate email, uploads a customer list to test a feature, and never thinks of it as a vendor relationship at all.

That gap is structural, not a failure of the program itself. The program catches exactly what it was built to catch: tools that ask for permission. It was never built to catch the ones that don’t.

Figure 1. The sanctioned path and the shadow IT path start from the same business need and diverge immediately after.

The Department-Level Blind Spot

Individual employees are not the largest source of this problem, departments are. A department head signing a contract with their own budget authority rarely feels like bypassing anything, since the purchase went through an approval chain. It simply wasn’t IT’s or security’s chain. That sense of legitimacy is exactly why department-led shadow IT is harder to surface than an individual signing up for a free trial: nobody internally flags it as irregular. This is also where the weakest identity and access management tends to show up, and not by accident. When IT is never involved in procurement, the tool never gets connected to the corporate identity provider. There is no single sign-on, no centralized multi-factor enforcement, and no automated deprovisioning tied to the organization’s offboarding process. Access typically runs on locally managed usernames, sometimes a shared login the whole team uses, and whether a departing employee’s access is actually revoked depends on whether someone remembers to do it manually. The weak identity controls that show up in these tools are not incidental. They are the predictable result of a tool that never entered a process requiring identity integration as a condition of approval.

The data exposure compounds the identity gap. Individual shadow IT tends to be scattered: one project management tool here, a file-sharing app there. Department-level tools are usually whole-function platforms, an HR benefits portal, a finance expense system, a sales CRM, that by design concentrate an entire category of regulated data: employee personal information, benefits and health-adjacent data, financial records, or customer PII. That is precisely the class of exposure PIPEDA’s accountability principle and OSFI B-10’s third-party scope are built to catch, and precisely what they miss when the relationship never crosses a desk that would have flagged it.

The Stakes Under OSFI B-10

For federally regulated financial institutions in Canada, this gap isn’t a best-practice concern so much as a guideline compliance one. OSFI’s B-10 Guideline on Third-Party Risk Management, which took effect in 2024, deliberately widened its scope beyond formal outsourcing contracts to third-party arrangements more broadly, scaled by risk and criticality rather than by how the relationship began. A tool an employee signed up for without going through procurement does not sit outside that scope simply because no one in the organization formally approved it. Ongoing monitoring, risk assessment proportionate to criticality, and board-level oversight of the third-party risk program are all expectations that apply to the relationship itself, not to whether it started with a signed contract or a personal credit card.

PIPEDA adds a second layer that applies the moment personal information is involved. Under its accountability principle, an organization remains responsible for personal data it transfers to a third party for processing, whether or not that transfer went through a formal review. A marketing tool that never touched procurement can still create a PIPEDA-relevant disclosure the moment a customer list is uploaded to it, and the organization’s obligations do not pause because security never had the chance to say no. That obligation played out in practice in May 2026, when U.S. community bank CB Financial Services disclosed in a filing with the Securities and Exchange Commission that an employee’s use of an unauthorized AI tool had exposed customer data, reportedly the first incident of its kind to cite shadow AI as the cause of a material cybersecurity disclosure. The filing triggered three obligations at once: SEC disclosure, a short-window notice to the bank’s prudential regulator, and customer notification under U.S. federal privacy law. A federally regulated Canadian institution facing the same scenario would face an equivalent cascade, to OSFI, to the Privacy Commissioner, and to affected customers, from a single unsanctioned tool no one in security ever reviewed.

What Is Actually at Risk

The risk was never simply that someone used a tool without asking. Third-party involvement in breaches doubled year over year, from 15% to 30%, according to Verizon’s 2025 Data Breach Investigations Report: an unassessed vendor is functionally indistinguishable from an assessed one that came through procurement. What’s actually at stake is everything a normal vendor assessment would have caught before that tool ever touched company data:

• No data processing agreement, which means no contractual limits on how that provider can use, retain, or resell the data
• No data classification review, which means sensitive or regulated data may be sitting in a tool with no encryption or access-control standard applied to it
• No breach notification clause, which matters directly under PIPEDA: if that provider is compromised, you may not learn about it in time to meet your own mandatory breach reporting obligations to the Privacy Commissioner and affected individuals
• No concentration risk visibility, which means the organization may already depend on a tool that leadership does not know exists

None of this requires the tool to be malicious. Ordinary, reputable SaaS products create this exposure simply by being adopted outside the process built to catch them.

Where Shadow IT Actually Hides

Discovery does not require an expensive platform to start. Most shadow IT surfaces through records the organization already keeps, once someone knows where to look at them for this specific purpose.

Figure 2. Six data sources that already exist inside most organizations, each capable of surfacing unsanctioned tools.

Expense reports and corporate card statements reveal recurring SaaS charges under an individual’s name rather than a department’s procurement code. OAuth and SSO grant reviews show which third-party applications have been given access to the corporate identity provider, frequently the single richest source of shadow IT discovery available. Network and DNS egress logs reveal where data is actually flowing, regardless of what anyone reported. Browser extension inventories catch the category that traditional software audits miss entirely. Departmental budgets, reviewed with finance, surface tools purchased below the threshold that triggers procurement review. Where a CASB is already in place, its cloud access logs are usually the fastest path of all.

One category is moving faster than the rest and deserves a specific mention: autonomous AI agents, built through low-code and no-code platforms and connected to systems like a CRM or a shared mailbox with no registered owner, no expiry, and no review. These are not a person using an unauthorized tool. They are a non-human identity taking actions on its own, often with standing privileged access nobody assigned deliberately. In May 2026, the Canadian Centre for Cyber Security joined a coordinated release with its counterparts in the United States, United Kingdom, Australia, and New Zealand calling for AI agents to be treated as a distinct identity category requiring least-privilege access and continuous behavioral verification, not governance bolted on after deployment. Where OAuth and SSO grant reviews used to be the way to find a forgotten SaaS subscription, they are quickly becoming the way to find an agent nobody remembers authorizing.

The cost of that blind spot is already on the record. In August 2025, attackers tracked as UNC6395 stole OAuth tokens belonging to Salesloft’s Drift chatbot integration and used them to reach into Salesforce environments at more than 700 organizations, including security vendors Cloudflare, Palo Alto Networks, and Zscaler. The attackers never touched Salesforce’s own infrastructure. They walked in through a third-party integration’s stolen tokens, the exact blind spot an OAuth grant review exists to catch, and one that a chatbot’s own users had no reason to think of as a vendor relationship at all.

Bringing It Into the Program, Not Banning It

Once a tool is discovered, the instinct is often to shut it down. That is usually the wrong first move. If people are already relying on it, removing access without a transition plan creates an operational gap and teaches the organization that discovery leads to punishment, which drives the next tool further underground rather than into the open. The more durable response is to route every discovered tool through the same risk-tiered assessment a sanctioned vendor would have gone through, retroactively. Classify the data involved. Determine whether a data processing agreement is achievable. Decide, based on actual risk rather than on how the tool arrived, whether it should be approved, replaced, or wound down on a reasonable timeline. The goal isn’t to punish the bypass; it’s to close it.

The Real Fix Is Upstream

Every recurring shadow IT discovery points to the same root cause: the sanctioned path is slower or more frictional than the business need it is meant to serve. A procurement process that takes six weeks to approve a twenty-dollar-a-month tool is not a control. It is an incentive to route around the control. Shrinking that gap, through a genuinely fast low-risk approval lane alongside the full assessment for anything higher-risk, does more to reduce shadow IT than any discovery tool ever will.

Shadow IT is not a discipline problem. It is the same third-party risk assessment gap repeating at every scale, from the individual employee to the department to the autonomous agent, that keeps getting a new name instead of a new assessment.

References

1. Office of the Superintendent of Financial Institutions. (2023). Third-Party Risk Management Guideline (B-10).
2. Office of the Privacy Commissioner of Canada. Personal Information Protection and Electronic Documents Act (PIPEDA), Schedule 1, Principle 1: Accountability.
3. Office of the Privacy Commissioner of Canada. (2018). Mandatory breach reporting under PIPEDA.
4. Canadian Centre for Cyber Security, in coordination with cybersecurity authorities in the United States, United Kingdom, Australia, and New Zealand. (2026). Joint guidance on treating AI agents as a distinct identity category.
5. Verizon Business. (2025). Data Breach Investigations Report.
6. Google Threat Intelligence Group and Mandiant. (2025). Widespread Data Theft Targets Salesforce Instances via Salesloft Drift.
7. CB Financial Services, Inc. (2026). Form 8-K filing. U.S. Securities and Exchange Commission.
8. National Institute of Standards and Technology. (2022). Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations (NIST SP 800-161 Rev. 1).
9. International Organization for Standardization. (2021). ISO/IEC 27036, Information security for supplier relationships.