Month: April 2026

Your employees are already using AI. They’re drafting emails in ChatGPT, summarizing contracts in Claude, building reports with Copilot, and asking Gemini to review vendor agreements. None of it went through IT. None of it was approved. And in most cases, nobody knows it’s happening.

This is shadow AI, and it’s now one of the fastest-growing security and compliance risks for mid-market Canadian businesses. This post breaks down what shadow AI is, what data is actually leaving your organization, and what a practical response looks like.

What Is Shadow AI?

The term distinguishes between AI tools that have been formally evaluated, licensed, and governed (such as Microsoft Copilot deployed through an M365 enterprise tenant) and those being used informally through personal accounts or free-tier access. The distinction matters because enterprise and consumer versions of the same product carry fundamentally different data handling terms.

How Common Is Shadow AI in the Workplace?

More common than most IT leaders assume. According to Microsoft’s 2025 Work Trend Index, 75% of knowledge workers now use AI tools in their daily work, and 78% are bringing their own AI tools to the job rather than waiting for employer-provided options. The report refers to this as “BYOAI” (Bring Your Own AI), and it is accelerating.

The gap between employee adoption and IT governance is significant. Most organizations have policies covering software installation, data classification, and acceptable use, but very few have updated those policies to explicitly address generative AI. In our conversations with GTA mid-market IT teams, the question “do you have an AI use policy?” is still answered with “not yet” more often than not.

What Data Are Employees Actually Putting Into AI Tools?

This is where the theoretical risk becomes concrete. Research from data security firm Cyberhaven found that 11% of the data employees paste into ChatGPT is confidential business data, including source code, financial records, client information, and internal strategy documents. That figure was measured across enterprise environments where employees knew their activity could be monitored.

The most documented example remains Samsung’s 2023 incident, in which engineers at the company’s semiconductor division pasted proprietary source code and internal meeting notes into ChatGPT while troubleshooting software bugs. The data was submitted before Samsung had an AI use policy in place. Samsung responded by banning generative AI tools across the company: a reaction that is effective but not sustainable for most organizations.

In practice, the most common categories of data entering AI tools without authorization include:

• Client contracts and proposals being summarized or edited
• Financial reports and budget documents being analyzed
• HR data including performance reviews and compensation information
• Internal technical documentation and system architecture details
• Personal information about clients, employees, or patients

Employees are not being reckless; they are being efficient. The problem is that efficiency and data governance are not the same objective, and without clear guidance, employees default to the tools that get the job done fastest.

Three Security Risks Shadow AI Creates

1. Data Transmitted to Third-Party Servers Without Your Control

When an employee submits a prompt to a consumer AI tool, that data travels to the vendor’s servers. For free and personal-tier accounts, OpenAI’s privacy policy historically allowed user inputs to be used to improve their models unless users opted out. Even with opt-outs enabled, the data has left your environment and sits on infrastructure you do not control, governed by terms of service your legal team has never reviewed.

2. No Audit Trail

Email is logged. File access is logged. Cloud storage has version history. Generative AI prompts submitted through a browser on a personal account leave no trace in your systems. If a compliance audit asks what client data was shared externally in the last 12 months, you cannot answer that question. If a confidentiality dispute arises, you have no record of what was disclosed and when. This is not a hypothetical gap; it is a gap in your controls right now.

3. Confidentiality Agreement and NDA Exposure

Most client-facing confidentiality agreements were drafted before generative AI existed. They prohibit disclosure of covered information to third parties, and submitting that information to a public AI model almost certainly constitutes disclosure, even if the employee’s intent was purely to get help with a task. The exposure is real whether or not a breach occurs. If a client or partner discovers their information was processed through an unapproved AI tool, the conversation with legal is not a comfortable one.

Shadow AI and Canadian Compliance: PIPEDA and PHIPA

Canadian businesses face specific compliance obligations that make shadow AI a regulatory issue, not just a security one.

Under PIPEDA (Personal Information Protection and Electronic Documents Act), organizations are responsible for personal information under their control, including information held by third parties on their behalf. When an employee submits personal information to a consumer AI tool without a data processing agreement in place, the organization is likely in breach of its accountability obligations under PIPEDA Principle 1, regardless of whether the employee acted intentionally.

For Ontario healthcare organizations and their vendors, PHIPA (Personal Health Information Protection Act) applies an even stricter standard. Submitting personal health information to any unauthorized third-party system including an AI tool, without explicit consent and a data custodian agreement is a reportable breach. The Office of the Information and Privacy Commissioner of Ontario has been explicit that AI tools are not categorically exempt from these requirements.

Approved vs. Unapproved AI Tools: What’s the Difference?

Not all AI tools carry the same risk. The critical variable is not which tool is used; it is what data agreement governs how that tool handles your information.

The pattern is consistent: enterprise-tier access with a signed data processing agreement is manageable. Consumer-tier access with a personal account is not, regardless of which AI provider is involved.

How to Build an AI Use Policy That Actually Works

Banning AI tools is not a realistic response. Employees will continue using them; the ban simply pushes activity further underground and adds compliance exposure without adding security. The goal is governance, not prohibition.

What to Do Right Now if You Have No AI Policy

If your organization does not yet have an AI use policy, you are not in a minority, but you are carrying avoidable risk. The practical starting point is not a comprehensive policy document; it is a two-step interim position you can communicate this week:

• Communicate a temporary rule: “Until we have a formal policy, do not submit client information, personal information, or anything covered by a confidentiality agreement to any AI tool you access through a personal account.” This is not a ban; it is a data minimization instruction your team can actually follow.
• Audit your enterprise AI tool access: Determine which AI tools your organization already has access to through existing software agreements: M365 Copilot, Google Workspace Gemini, GitHub Copilot for developers. These are your sanctioned options. Communicate them clearly so employees have an approved path rather than defaulting to personal accounts.

At Balanced+, we help GTA mid-market businesses build practical AI governance frameworks as part of broader IT and cybersecurity programs, including data classification, DLP configuration, and employee training. If you want to understand where your current AI exposure sits, a cybersecurity assessment is a good starting point. It is not a sales process it is a structured look at where the gaps are.

Frequently Asked Questions

What is shadow AI, and how is it different from shadow IT?

Shadow IT refers to any software or system used by employees without IT approval: unauthorized apps, personal cloud storage, unapproved SaaS tools. Shadow AI is a specific subset of shadow IT focused on generative AI tools like ChatGPT, Gemini, and Claude. The key difference is the data risk: shadow IT introduces unapproved software into your environment, while shadow AI actively transmits data out of your environment to third-party servers, often with no visibility or audit trail.

Is it a compliance violation for employees to use ChatGPT at work?

It depends on what data is involved and what account type is used. Using ChatGPT through a personal or free account to submit client personal information, health data, or information covered by a confidentiality agreement likely creates a PIPEDA or PHIPA compliance issue, and may breach contractual obligations with clients. Using ChatGPT Enterprise under a signed data processing agreement with proper controls is a different matter. The tool itself is not the determining factor; the governance terms and data involved are.

Can I just ban AI tools to avoid the risk?

You can issue a ban, but it will not eliminate the risk; it will push activity underground and remove whatever visibility you currently have. Employees who rely on AI tools to do their jobs will continue using them; they will simply avoid mentioning it. A more effective approach is to define approved tools with enterprise data agreements, publish clear rules about which data categories are off-limits regardless of the tool used, and monitor usage through available admin consoles. Governance is more durable than prohibition.

What should an AI use policy include for a mid-market Canadian business?

At minimum: a list of approved AI tools and the specific account type required (enterprise, not personal); a list of data categories that cannot be entered into any AI tool regardless of approval status (personal information, health data, client confidential data, source code); a process for employees to request approval for new AI tools; and a reference to existing data classification and acceptable use policies. For businesses subject to PIPEDA or PHIPA, the policy should also address third-party data processing agreements and how AI tool vendors are evaluated for compliance.

Your CFO wants to know why the cybersecurity line item doubled. Your IT manager wants 24/7 monitoring. Your insurer wants proof of an incident response plan. Somewhere in those three conversations, someone said the word “MSSP,” and now you’re trying to figure out if that’s different from the MSP you’ve been working with for years.

It is. Here’s what separates a Managed Service Provider from a Managed Security Service Provider, what each actually delivers, and how to decide which one (or both) your business needs.

The core difference: operations vs. security outcomes

An MSP is measured on uptime, ticket resolution, and user productivity. The KPIs are mean-time-to-resolution, system availability, and helpdesk satisfaction. When something breaks, the MSP fixes it. When you onboard a new employee, the MSP provisions their laptop, M365 license, and access permissions.

An MSSP is measured on threat detection and containment. The KPIs are mean-time-to-detect (MTTD), mean-time-to-respond (MTTR), and risk reduction. When a phishing email lands, the MSSP catches the credential theft attempt before lateral movement. When ransomware tries to execute, the MSSP isolates the endpoint within minutes, not hours.

The distinction matters because the skill sets, tooling, and operating models are genuinely different. A skilled systems administrator is not a SOC analyst, and a SOC analyst is not a network engineer. Conflating the two is how organizations end up with a green-light dashboard and a breach in progress.

What does an MSP actually do?

An MSP handles the day-to-day IT operations that keep your business functional. Engagements are typically structured around a per-user or per-device monthly fee covering a defined scope of services, with project work billed separately.

• Helpdesk and end-user support (Tier 1 to 3)
• Server, network, and endpoint management
• Microsoft 365 and Google Workspace administration
• Backup, disaster recovery, and business continuity
• Patch management and software updates
• Vendor management (ISP, SaaS, hardware)
• IT strategy, budgeting, and lifecycle planning (vCIO)

Most MSPs include a baseline of security hygiene: endpoint antivirus, basic email filtering, MFA enforcement, patching. That’s table stakes, not security operations. It’s the equivalent of locking the doors. It’s not the equivalent of a monitored alarm system with a response team.

What does an MSSP actually do?

An MSSP delivers continuous cybersecurity monitoring, detection, and response, almost always built around a 24/7 Security Operations Centre. The economics only work at scale: a single SOC analyst earning a Toronto salary cannot watch your environment around the clock, but a shared SOC across hundreds of clients can.

• 24/7 SOC monitoring with human analyst escalation
• Managed detection and response (MDR) on endpoints
• SIEM (Security Information and Event Management) for log aggregation and correlation
• Threat intelligence and threat hunting
• Vulnerability management and penetration testing
• Managed firewall, IDS/IPS, and email security
• Incident response and forensic investigation
• Compliance reporting (PIPEDA, PHIPA, SOC 2, ISO 27001)

The Canadian Centre for Cyber Security has consistently flagged ransomware and business email compromise as the top threats facing Canadian organizations in its National Cyber Threat Assessment. Both threat categories share a defining feature: they’re caught by behavioural monitoring, not by antivirus.

MSP vs MSSP: side-by-side comparison

What does it cost to run security in-house instead?

The reason mid-market firms outsource to an MSSP is straightforward: the in-house math doesn’t work below roughly 500 employees. A functional 24/7 SOC requires a minimum of five to six analysts to cover three shifts with vacation and sick coverage, plus a SOC manager and tooling.

Toronto-area SOC analyst salaries currently run $85,000 to $120,000 CAD for intermediate analysts and $130,000 to $170,000 for senior. Add SIEM licensing (often $50K to $150K annually for mid-market log volumes), EDR tooling, threat intel feeds, and training, and the all-in cost of a basic in-house SOC clears $1M CAD per year before it catches a single threat. An MSSP delivers equivalent coverage to a 200-person firm for a small fraction of that.

When do you need an MSP, an MSSP, or both?

How to evaluate MSSP capabilities (the questions that filter out resellers)

The MSSP market has a quality problem: many providers labelled “MSSP” are really MSPs reselling a third-party SOC platform with minimal value-add. From a security operations standpoint, here’s how to tell the difference during a sales conversation.

• Where is the SOC? Owned and operated, or white-labelled from a vendor? Both can work, but you should know which.
• What’s your MTTD and MTTR? If they can’t quote contractual SLAs in minutes (not hours), keep looking.
• Which SIEM/EDR platforms? Named tools matter. “Industry-leading” is not an answer.
• Do analysts actually triage, or just forward alerts? Alert forwarding is not detection and response.
• What’s your incident response retainer? Containment is included; deep forensics may not be.
• What compliance frameworks do you map controls to? SOC 2, ISO 27001, NIST CSF, CIS Controls. Pick yours and ask.

The hybrid MSP/MSSP model: why it’s winning mid-market

Five years ago, the prevailing advice was to keep your MSP and your MSSP separate. The assumption was that the firm running your environment shouldn’t also be the firm grading its security. That logic still holds at enterprise scale, where independence matters for audit purposes.

For mid-market Canadian firms, the calculus is different. Two-vendor models create attribution gaps: when something breaks, the MSP blames the MSSP’s blocking rule, the MSSP blames the MSP’s misconfiguration, and you spend three days in finger-pointing meetings. A hybrid provider with mature internal separation of duties (distinct ops and security teams, separate change-control workflows, independent reporting lines) eliminates the gap without sacrificing oversight. In our work with GTA mid-market firms, this is the model that consistently produces the fastest containment times.

If you’re trying to figure out whether your current MSP is actually delivering security, or whether you need to layer in an MSSP, our team can walk you through a practical capability gap assessment against your insurance requirements and compliance posture. Start with our managed cybersecurity services overview, or learn about our 24/7 MDR offering built on Fortinet’s security fabric.

Frequently asked questions

Is an MSSP more expensive than an MSP?

Per-user, MSSP services are usually cheaper than MSP services because the scope is narrower: security monitoring versus full IT operations. Mid-market MSSP coverage typically runs $15 to $60 CAD per endpoint per month plus a base SOC fee, while full MSP services run $125 to $225 per user per month. Most businesses end up paying for both, with the combined cost still dramatically lower than building either function in-house.

Can an MSP also be an MSSP?

Yes, and this hybrid model is now the dominant approach for mid-market Canadian firms. The critical requirement is genuine internal separation of duties: distinct security and operations teams, independent reporting, separate change-control. A provider that delivers both functions out of the same overworked helpdesk is not a hybrid MSP/MSSP; it’s an MSP with a marketing slide.

Do I need an MSSP if I have cyber insurance?

Most likely yes, and increasingly your insurer will require it. Canadian cyber insurance carriers have moved toward mandating 24/7 monitoring, MDR on endpoints, and tested incident response as conditions of coverage. Without an MSSP (or equivalent in-house SOC), you may have a policy that pays out only after the carrier verifies controls were in place at the time of the incident.

What’s the difference between an MSSP and MDR?

MDR (Managed Detection and Response) is a specific service category typically delivered by an MSSP. MDR focuses on endpoint and network behavioural detection with active response capability: isolating compromised devices, killing malicious processes, blocking attacker IPs. An MSSP’s portfolio usually includes MDR alongside SIEM management, vulnerability management, compliance reporting, and incident response. MDR is one tool in the MSSP toolbox, not a substitute for the broader function.

IT compliance is one of those terms that gets thrown around in boardrooms and vendor pitches, but rarely explained in plain language. If you are a business owner, COO, or IT manager at a mid-market company, understanding what IT compliance actually means is the first step toward protecting your organization from regulatory penalties, data breaches, and lost client trust.

This guide breaks it down: what IT compliance is, why it matters for Canadian businesses, what frameworks apply to you, and what a managed IT provider actually does to keep you compliant.

IT Compliance, Defined

Common IT Compliance Frameworks in Canada

The frameworks that apply to your business depend on your industry, where your data lives, and who you do business with. Here are the ones mid-market companies in the GTA encounter most often:

PIPEDA (Personal Information Protection and Electronic Documents Act)

Canada’s federal privacy law. It applies to every private-sector organization that collects personal information in the course of commercial activity. If you handle customer data, names, emails, financial details, health information, PIPEDA applies to you. Under the act, organizations must obtain meaningful consent, limit data collection to what is necessary, and implement appropriate security safeguards.

PHIPA (Personal Health Information Protection Act)

Ontario’s health privacy legislation. If your organization is a health information custodian or processes personal health information on behalf of one, PHIPA imposes strict requirements on access controls, audit logging, breach notification, and data residency.

Ontario Bill 194 (Strengthening Cyber Security and Building Trust in the Public Sector Act)

A newer piece of legislation that expands cybersecurity and privacy obligations for Ontario’s broader public sector, and signals where private-sector regulations are headed. If your organization works with public-sector clients, understanding Bill 194 is essential.

SOC 2

A voluntary framework developed by the AICPA that evaluates an organization’s controls around security, availability, processing integrity, confidentiality, and privacy. SOC 2 Type II certification is increasingly required by enterprise clients and partners before they will sign a contract. If your sales team keeps hearing “do you have SOC 2?”, this is what they mean.

PCI DSS (Payment Card Industry Data Security Standard)

If you process, store, or transmit credit card data, PCI DSS compliance is mandatory. Requirements include network segmentation, encryption, access controls, regular vulnerability scans, and penetration testing.

NIST Cybersecurity Framework

A widely adopted voluntary framework from the U.S. National Institute of Standards and Technology. Many Canadian organizations, and their cyber insurance providers, use NIST CSF as a baseline for evaluating security maturity. It organizes controls into five functions: Identify, Protect, Detect, Respond, and Recover.

Why IT Compliance Is Hard for Mid-Market Companies

Enterprise organizations have dedicated compliance teams, GRC platforms, and seven-figure security budgets. Small businesses often fly under the radar. Mid-market companies get the worst of both worlds: they are large enough to be targeted by regulators and attackers, but rarely have the in-house staff to manage compliance properly.

Common challenges include:

• Overlapping frameworks. A healthcare company processing credit cards may need to satisfy PHIPA, PIPEDA, PCI DSS, and SOC 2 simultaneously, each with different controls, evidence requirements, and audit cycles.
• Continuous monitoring. Compliance is not a one-time project. Frameworks require ongoing evidence collection, policy reviews, vulnerability scanning, and access audits.
• Documentation burden. Auditors do not just want to see that you have controls, they want documented policies, procedures, and evidence that those controls are enforced consistently.
• Evolving requirements. Regulations change. New legislation like Ontario Bill 194 can shift your obligations overnight. Staying current requires dedicated attention.
• Talent gap. Compliance-qualified IT professionals are expensive and hard to find. A mid-market company competing with banks and tech firms for GRC talent is fighting an uphill battle.

What a Managed IT Provider Does for IT Compliance

This is where the confusion usually starts. Many business leaders assume that hiring a managed IT provider means compliance is “handled.” The reality is more nuanced, but a good provider does take significant compliance burden off your plate.

Here is what a managed IT compliance engagement typically includes:

IT Compliance Is Not Just a Security Problem

It is tempting to treat compliance as a subset of cybersecurity. In practice, IT compliance touches every part of your technology environment:

• HR and onboarding: How are user accounts provisioned and deprovisioned? Is access reviewed when employees change roles?
• Procurement: Are your vendors assessed for security risk? Do your contracts include data processing agreements?
• Operations: Are your backup and disaster recovery procedures documented and tested? Can you prove it?
• Finance: If you process payments, are your systems PCI-compliant? Is cardholder data isolated?

How to Evaluate a Provider’s Compliance Capabilities

Not every managed IT provider is equipped to handle compliance. When evaluating a partner, ask:

• Which frameworks do you have direct experience with? Generic “we do compliance” answers are a red flag. You want specifics: SOC 2 Type II, PCI DSS v4.0, PHIPA, NIST CSF.
• Is your own organization certified? A provider that has achieved SOC 2 certification themselves understands the process from the inside, not just theoretically.
• How do you handle evidence collection? Manual spreadsheets signal immaturity. Look for automated evidence collection integrated with your existing tooling.
• What is your remediation process? When a gap is identified, how quickly is it addressed? Is remediation included in the engagement, or billed separately?
• Can you support multiple frameworks simultaneously? If you need SOC 2 and PCI DSS, your provider should map overlapping controls rather than running two separate projects.

Getting Started with IT Compliance

If your organization has not formally addressed IT compliance, the path forward is straightforward:

IT compliance is not a checkbox exercise. It is an ongoing operational discipline that protects your business, satisfies your clients, and keeps regulators at arm’s length. The question is not whether you need it, it is whether you are doing it well enough.