For years, the conversation we’d have with a leader on Business Standard went something like this. “Premium costs more. Standard covers what my team uses: email, Teams, Office apps. The security stuff in Premium sounds like something for bigger companies.” That was an arguable position when the gap was wider and the threat picture was quieter. Neither is true anymore.

Premium includes the controls Standard lacks for current attacks: conditional access (rules about who can sign in, from where, on what device), Intune for managing the laptops and phones touching your data, Defender for Business and Defender for Office 365 for endpoint and email threat protection, and information protection controls for labeling sensitive documents. Those controls used to feel like enterprise extras. Now most businesses need them.

These aren’t luxury features. Consider session token theft, where an attacker steals the credential your browser uses to stay signed in and walks right past MFA. Or business email compromise, where someone lives inside a mailbox for weeks setting up a fake invoice. The defenses that matter against those attacks are largely on the Premium side of the line. The Microsoft Digital Defense Report 2025 found that 52% of cyberattacks with known motives were driven by extortion or ransomware. It also found that phishing-resistant MFA can block over 99% of identity-based attacks. That control is enabled by Business Premium’s Conditional Access and Entra ID P1. The gap between “we have MFA on” and “we have MFA configured the way Premium lets us configure it” is most of the risk.

When we do onboarding assessments, a Standard tenant and a Premium tenant can carry nearly the same cost per user and still look nothing alike in what we can configure. On Standard, we can turn on MFA, clean up admin accounts, and set some sensible defaults. Past that, the levers run out. On Premium, we can set conditional access policies that block sign-ins from unusual locations, require compliant devices, and quarantine risky sessions. We can push consistent settings to every laptop. We can see what’s happening on those endpoints when something goes wrong. You start from a safer baseline.

For years the counter-argument was cost, and it was a fair one. On a 40-person company, the delta between the two plans was roughly $4,500 a year. Still is. That math looks different now that more than half of motivated attacks are aimed at extortion and ransomware, and the controls that block the identity-based path in are the ones sitting behind the Premium license.

The better question is: “Why are we paying nearly the same money for less protection?”

Then there’s the insurance side. Your cyber insurer is now asking about the specific controls Premium enables. Conditional access. Managed devices. Endpoint detection. If your carrier’s questionnaire asks whether you enforce device compliance for access to email, “no” is an increasingly expensive answer. Sometimes it’s a decline-to-renew answer. Any license savings can disappear through a higher insurance premium, a lower coverage limit, or a larger retention.

Premium will not fix the problem by itself. The license only gives you access to the controls. Configuring conditional access policies, enrolling devices in Intune, tuning Defender, writing the exception process for the executive who travels internationally, that’s real work. Someone has to do the configuration work: internal, partner, or both. Buying Premium and leaving it in the box gives you a heavier receipt and roughly the same security posture as Standard.

But you can’t configure controls you don’t have licensed. Get that part right first.

If you’re heading into your next renewal, a few questions worth working through with whoever handles your IT.

What Microsoft plan are we on right now, and what’s the delta to Premium given the new pricing? The math shifted this year. Redo it.

If we moved to Premium, what would we turn on in the first 90 days? Conditional access, Intune enrollment, Defender policies. If your provider or internal team can’t sketch a rollout, that’s a different conversation to have.

What does our cyber insurance renewal look like in the next 12 months, and what controls will the carrier ask about? If the answer includes conditional access or managed devices, the licensing question is already partly answered.

Is there anyone in our environment (often an owner, or whoever set the tenant up years ago) whose everyday account also has global admin rights? Premium doesn’t fix that on its own, but the identity controls make it easier to contain the damage if that account gets compromised.

Microsoft didn’t announce “Premium is the new floor” this year; the pricing said it for them. Every SKU below Premium got more expensive, and Premium held. That tells you where Microsoft thinks business tenants should be, and it matches what we see in incident response and insurance renewals.

If you haven’t looked at your Microsoft licensing since your last renewal, now is a good time. Not because Microsoft told you to. Because the ground moved.

Leaders deserve a clearer answer than “well, no security is perfect.”

MFA didn’t get weaker. The floor for attacking it dropped.

Five years ago, the attacks that beat MFA needed a real operator on the other end. Skilled, patient, custom tooling. Today those same attacks ship as kits. Sekoia.io tracks the adversary-in-the-middle phishing-kit market at under $350 a month, which means someone with roughly $250 in crypto and a Telegram channel can run kit-quality MFA-bypass campaigns. That’s what changed, and it changes what “we have MFA” actually buys you.

Most of the break-ins come from three familiar attacks.

Start with prompt bombing. An attacker has your password (purchased, phished, or reused from somewhere else) and starts hammering the login button. Your phone buzzes. Approve? No. Buzzes again. Approve? No. Buzzes at 2am. Buzzes during a meeting. Buzzes while you’re driving. Eventually somebody taps yes to make it stop. That’s the whole attack. There’s no genius on the other end.

SIM swapping works differently. An attacker calls your mobile carrier, cons the rep, and gets your phone number moved to a SIM card they control. Your texts now go to them. If your MFA is “we’ll text you a code,” your MFA now belongs to them too. This used to be a targeted attack on crypto traders and executives. It’s now run at scale.

The hardest one to spot is real-time phishing, the adversary-in-the-middle attack those cheap kits are built for. You click a link, land on what looks exactly like your Microsoft 365 login page, type your password, get prompted for your code, type that too. The page in the middle is relaying everything to the real Microsoft login in real time and capturing the session token at the end. You log in successfully. So do they. Microsoft’s 2025 Digital Defense Report attributed 80% of MFA-bypass breaches to session-token theft, which is the prize at the end of that attack.

In all three cases, the user did the MFA. The MFA worked the way it was designed to work. The attacker still got in.

What should a leader do on Monday? Start with work your team or IT provider can begin this week.

Move everyone to phishing-resistant MFA: FIDO2 security keys or passkeys, which only release credentials to the real site, not a lookalike. There’s a temptation to scope this to “high-risk” accounts (finance, HR, IT admins, leadership), but the business manager whose mailbox got hit probably wasn’t on anyone’s high-risk list either. Every account is a way in, and every account leads somewhere.

Turn on number matching, which kills prompt bombing by requiring you to type a two-digit number from the login screen into your phone instead of just tapping approve.

Use conditional access to narrow the windows. Block logins from countries you don’t operate in, require a managed device for admin accounts, re-prompt when something looks off. Conditional access does need careful configuration and ongoing tuning. Otherwise you’ll lock out your bookkeeper the week she’s working from Mexico, so this is a policy conversation, not a one-time toggle.

These controls are already sitting in licenses many organizations pay for. The reason it’s not already in place isn’t usually negligence. It’s that the people running your IT, whether that’s an internal admin or a managed IT services provider, are juggling fifty other fires, and “MFA is on, we’re fine” was a defensible answer until pretty recently.

It’s not a defensible answer anymore.

Here’s the one question worth bringing to your team or IT provider this week:

“Which of our accounts are still using SMS or basic approve/deny MFA, and what’s our plan to move them all to phishing-resistant MFA this quarter?”

The answer, more often than it should be, is the owner. Or the office manager. Or the person who set the whole thing up six years ago and never thought about it again. Their everyday email (the one they use to send quotes, open PDFs from strangers, click links from vendors, sign into apps on their phone) is also the account that can do anything inside the environment. Reset anyone’s password. Read anyone’s mail. Turn off security controls. Wipe a laptop. Hand the same keys to someone else.

That’s the tell. When the daily-use account and the top-level admin account are the same account, nobody has been thinking about how bad a bad day could get.

Picture it this way. If this account gets compromised (phished, password reused on some breached site), how far does the damage reach? When it’s the top-level admin, the answer is “everywhere.” Email, files, identities, backups, settings, the whole environment. One bad click and an attacker doesn’t just get into one mailbox. They own the place.

There are two fixes, and most organizations skip both. They’re not exotic. They’re not expensive. Microsoft has recommended them for years. The honest reason they get skipped is that they take real hours to set up, and someone has to make the case for spending those hours when nothing is currently on fire. That’s a hard sell internally, and it’s a hard sell to a client when the invoice shows up. Often there are just too many other fires to put out, and this isn’t one of them yet. So it sits.

The first fix: a separate admin account you only sign into when you need it. Your everyday account, the one used for email and Teams and the apps on your phone, has no admin rights at all. When you need to do something administrative, you sign into a different account that exists only for that. Different username, different password, different MFA. The account exposed to the internet all day, clicking links and opening attachments, is not the account that can blow up your environment. If it gets compromised, the damage stops at one person.

The second fix is giving people only the access they actually need. Stop handing out top-level admin as the default. Someone who resets passwords for the help desk doesn’t need it. Someone who manages email groups doesn’t need it. Someone who handles new hires and departures doesn’t need it. Microsoft 365 has more specific roles for all of these. They give people what they need to do their job and nothing more.

This one gets skipped because it takes extra thought and care. Figuring out who needs to do what, and matching that to the right role, is a small project. It’s easier to just make everyone a top-level admin and move on. That’s how it quietly becomes the norm. Three people need to do “some admin stuff,” three people get full keys, and nobody ever revisits it. If one of those accounts gets compromised, or one of those people leaves on bad terms, the damage is the same as if the owner’s account got hit.

This is one of the quieter reasons IT support for a small business looks different than people expect. The flashy work is the new laptop, the migration, the helpdesk ticket closed in twenty minutes. The work that actually saves the company is the boring inventory of who has what, and the patience to keep it tidy over time. Whether that work happens inside the building or through outsourced IT, somebody has to own it. If nobody owns it, it doesn’t happen.

This isn’t about distrust. It’s about containment. The fewer rights any one account has, the smaller the damage when something goes wrong. And something will go wrong eventually. That’s the whole reason we’re talking about this.

A worthwhile thing to do this week: open your Microsoft 365 admin center, go to Roles, and look at who has Global Administrator assigned. If the list includes the everyday email accounts of people who use those mailboxes all day, you’ve found a real problem. In a small business, more than two or three names is usually a flag too. In a larger org, the right number scales up, but the principle holds: it should be a deliberate list, not an accidental one.

Then have the conversation with your team or your managed IT services provider. Not “are we secure.” That question is too big to answer usefully. Ask the specific one: “Who has what admin permissions in our environment, why do they have it, and what would happen if any one of those accounts got phished tomorrow?”

The difference shows up in how the work moves. When you delegate a task, you stay in the loop. You’re approving, nudging, checking in, holding the outcome in your head. When you delegate a function, someone else owns the outcome and moves it forward whether you’re watching or not.

Picture a strong finance lead who owns the function. Budgets get built, forecasts get updated, the audit gets scheduled, cash gets watched. None of it waits on you to ask. Now picture a bookkeeper you have to poke every month to send the close report. Same domain, completely different relationship.

The same pattern shows up in marketing, HR, facilities, and IT.

This is where the conversation about managed IT services tends to go sideways. Leaders evaluate providers on task-level questions: how fast does the helpdesk respond, how quickly do tickets close, how smoothly do new users get set up. Those questions matter. They just aren’t function-level questions. They’re dispatching questions wearing a managed-services costume.

A function-level question sounds different. Does the proactive work that nobody is going to nag anyone about actually happen?

Things like: the annual IT plan that ties technology decisions to where the organization is actually going. The IT budget that doesn’t surprise the board in March. The lifecycle roadmap that says which devices and systems are aging out and when. The cybersecurity audit that gets scheduled because it’s time, not because something broke. The risk review that surfaces what’s quietly drifting. The governance conversation about Microsoft 365, or Copilot, or AI tools that staff are already using whether you’ve sanctioned it or not.

Nobody is going to file a ticket for any of that. It only happens if someone owns it.

A quick example of what function-level ownership actually looks like in practice. We worked with an engineering firm where the brief wasn’t “fix this ticket” or “stand up this server.” It was: build a phased IT roadmap, reduce reliance on aging in-house servers, get SOLIDWORKS workloads into Azure, and set the team up for flexible remote work with centralized cloud storage. That’s a function-level engagement. The output wasn’t a faster helpdesk. The output was a hybrid environment with less complexity, a scalable cost model that grows with the team instead of front-loading capital expense, and the security posture that comes with running inside Microsoft 365. None of that work was going to surface from a ticket queue. Someone had to be thinking about it on the firm’s behalf.

Here’s a test worth running: if you went on a three-month sabbatical tomorrow, would your IT function still move forward? Would the planning happen? Would the renewal conversations get scheduled? Would the risks get surfaced? Would you come back to find decisions waiting for you, or work already moving?

If the honest answer is that tickets would keep closing fast enough that nobody complains, but nothing forward-looking would happen, you haven’t handed off a function. You’ve outsourced a queue. That’s a real service. It just isn’t the same thing.

This is also the question to sit with before deciding whether to outsource IT or build it in-house. The choice isn’t really internal vs. external. It’s queue vs. function. A small in-house team can own the function beautifully if that’s what you’ve asked them to own. An outsourced IT partner can own it too. Either one can also drift into pure dispatch mode if nobody is clear about the brief.

The distinction matters more than it used to, because identity, security, data governance, productivity tooling, vendor sprawl, and employee experience are all being re-examined at once. The organizations that handle this well are the ones where someone is actively thinking about all of that on their behalf, not just reacting when something breaks.

And here’s the part worth sitting with: this isn’t a vendor problem first. It’s a leadership problem first. If you’ve never asked your IT partner (or your internal team) to own the function, they’ve probably defaulted to owning the queue. That’s a rational response to how they’ve been measured. The fix isn’t necessarily a new provider. The fix is changing the conversation about what you’re asking them to own.

A few questions that get at this directly:

What’s our IT plan for the next twelve months, and how does it connect to the business plan? Where are we on the technology lifecycle, and what’s the replacement schedule? What’s our current cybersecurity posture, and what’s changed since last review? What are the top three risks in our environment right now, and what are we doing about each? Where is shadow IT or shadow AI showing up, and how are we responding?

If those questions get answered crisply, without scrambling, you’ve handed off a function. If they get answered with “let me get back to you” or “we’d need to look into that,” you’ve got a dispatcher, not an owner.

This question becomes especially important for organizations responsible for managing client data, whether due to insurance requirements, legal obligations, or commitments made to clients about how their information is managed. 

What Is AI Data Residency? 

Data residency refers to the geographic location where your data is physically stored. When you type a prompt into an AI system, the data can be processed on servers anywhere in the world. If those servers are in Canada and owned by a Canadian company, the data remains in Canada and will be subject to Canadian Privacy Law, including PIPEDA. If the data is stored at rest on servers in another country, the data may be subject to that country’s privacy laws.  

However, due to the Cloud Act in the United States even if the server is in Canada, the US government can gain access to that data if the server is owned by an American company. This does not mean that the US government has unlimited access to data stored on American owned servers. It also does not mean storing data with American companies violates PIPEDA. It is, however, important for business leaders to understand who can access their data under what circumstances. 

For Canadian business owners, data residency is not just a technical detail – it affects privacy obligations, client trust, and risk exposure.  Business leaders have the ultimate responsibility of ensuring they have a well-configured and secure account to protect client data, regardless of where the data is stored. 

ChatGPT and Canadian Data Residency 

If employees are using the free version of ChatGPT, their data is generally stored and processed in the United States. The same applies to lower-tier paid plans such as Plus and Team. These plans do not currently offer Canadian data residency meaning that company information entered into those accounts is primarily handled through U.S.-based servers and may be subject to further American legislation, such as the Stored Communications Act. 

Paid plans do offer stronger privacy controls than the free version. For example, business subscriptions can limit whether the data is used to improve public models. This is an important distinction for companies that are concerned about confidential information being reused by the model. Even with these improvements, the data storage is still primarily stored outside of Canada. 

ChatGPT Enterprise is where things change. Enterprise and Education customers have the option to store their data “at rest” in Canada or other supported regions.  

In practical terms, if Canadian data residency is a requirement for your organization, Enterprise deployment is currently the only ChatGPT option that supports it. Even then, it is important to understand that some limited technical processing or metadata may still occur outside Canada. As with all global cloud systems, this is an unavoidable and common practice.  

The key takeaway for Canadian businesses is straightforward: the safety of ChatGPT for business use depends heavily on the subscription level, how it is configured, and what information your team enters into it. 

Microsoft Copilot and Canadian Data Residency 

Microsoft Copilot operates within your organization’s Microsoft 365 environment. For many Canadian organizations already using Microsoft 365, this simplifies the conversation around AI data residency. 

If your organization’s Microsoft tenant is configured in Canada, Copilot generally follows those same regional settings. It also operates within Microsoft’s enterprise security framework, meaning your business data is not used to train public AI models and remains inside your organization’s boundary. 

However, configuration still matters. If your tenant is not set up with Canadian data residency, your data may be stored elsewhere. If your Microsoft 365 environment is in line with your organization’s needs, then your Copilot license will be as well. 

Enabling Copilot can be a great opportunity for businesses to review their security settings. If you are concerned about data residency and security with AI, Copilot is considered the safest option. 

Google Gemini and Canadian Data Residency

Google Gemini, integrated into Google Workspace, follows a similar pattern as Microsoft Copilot. Business-level subscriptions provide administrative controls and do not use company data to train public AI models. Data residency depends on how your Google Workspace environment is configured. 

If your organization has selected a Canadian region for data storage, your information will remain there. If not, it may be stored in another country. Like Copilot, the product itself is only part of the equation. The way your environment is set up determines where your data lives. 

For Canadian companies evaluating Gemini, the right question is not simply whether the tool is secure, but rather if your Google configuration aligns with your data residency expectations. 

The Real Risk: Unmanaged AI Use 

In many organizations, the biggest risk is not the AI platform itself.  Instead, it is the absence of structure around how employees are using it. 

Across Canada, staff are experimenting with AI every day. They paste client emails into ChatGPT to rewrite them. They summarize financial data. They draft HR responses. They brainstorm strategy documents. Most of the time, employees are trying to be more productive, not careless. 

The issue is that leadership often has no visibility into this activity. There is no approved tool, no clear policy, or guidance on what can and cannot be entered into AI systems. Without this regulation, an organization can lose control of their data without realizing it. When it is unmanaged, risk grows quietly in the background. 

Canadian business owners must consider whether the AI use inside their organization is intentional and governed. When companies standardize approved tools, understand AI data residency in Canada, and set clear internal guidelines, AI can be used confidently and securely.  

Does Data Residency Matter for Every Business? 

Just because your company’s data is stored on servers outside Canada does not automatically make it unsafe. Large cloud providers such as OpenAI, Microsoft, and Google operate highly secure global infrastructure. In many cases, these international data centers have stronger physical and digital security controls than what most small or mid-sized businesses could ever implement internally. 

For many Canadian businesses, especially those in less-regulated industries, storing data in the United States may present little practical risk. U.S.-based cloud infrastructure is mature, secure, and widely used by Canadian companies every day. 

Where data residency becomes more important is in situations such as: 

• Highly regulated industries 

• Government or public sector work 

• Organizations with strict contractual data location requirements 

• Businesses handling sensitive personal, health, or financial information 

In those cases, the data can carry legal, contractual, or reputational implications. For others, it may simply be a matter of preference rather than necessity. The key is understanding what regulations you are bound by and what you can do to ensure your tools aren’t compromising your commitments to data security. 

A More Balanced Way to Think About AI and Data Location 

AI adoption does not need to be driven by fear. It should be driven by informed decisions. 

International cloud systems are not “less secure” simply because they are outside Canada. In fact, the global infrastructure operated by major providers is designed to meet extremely high security standards. Encryption, access controls, monitoring, and compliance certifications are standard practice. 

Instead of asking if foreign servers are dangerous, business leaders need to ask if the organization has legal, regulatory, or contractual reasons to keep data in Canada. 

If the answer is yes, then Canadian data residency should be part of your AI decision-making process. 

If the answer is no, the focus may shift more toward choosing the right subscription level, setting clear internal policies, and ensuring employees are using approved tools appropriately. 

Sources 

• Data residency and inference Residency for ChatGPT | OpenAI Help Center 

• Gemini Enterprise Standard and Plus Editions data residency and ML regional processing commitments  |  Google Cloud Documentation 

• Data Residency for Microsoft 365 Copilot and Copilot Chat – Microsoft 365 Enterprise | Microsoft Learn 

That era is ending, and some leaders haven’t caught up to what’s replacing it.

Your cyber insurer is quietly becoming one of the more consequential auditors of your IT environment. Not in the traditional sense, where someone gives you a finding and a remediation date. The underwriter’s audit is the one that runs after an incident, when the question isn’t “what do we fix by Q3” but “does the policy actually pay.”

Look at what’s driving the shift. The Insurance Bureau of Canada reports that Canadian cyber premiums climbed from $18 million in 2015 to $550 million in 2023. And yet from 2019 through 2023, insurers paid out roughly $1.53 in claims for every $1 they collected in premium. That’s not a sustainable book of business. It’s a market that has to tighten or collapse, and tightening is what we’re seeing.

Tightening doesn’t only mean higher prices. It means underwriters are now grading deployment depth, not checkbox presence. They want to know not just whether you have MFA, but whether it’s phishing-resistant, and whether it’s deployed on the accounts that matter. They want to know not just whether you have endpoint detection and response (EDR), but what percentage of your laptops, workstations, and servers it actually covers. Marsh McLennan’s 2025 cyber risk study put numbers on it: each 25% jump in EDR coverage cut breach probability by 10%, and phishing-resistant MFA users were 9% less likely to suffer a cyber event than those on weaker MFA. Underwriters have read that study too.

Then there’s the part that should make every leader pause. Coalition’s 2024 claims data found that 82% of denied cyber insurance claims involved organizations that hadn’t fully implemented the MFA they had attested to.

Read that again. Most denied claims came from organizations that thought they had coverage. They paid the premium. They filed the policy. Then something went wrong, the adjuster came in, and the gap between the application and the environment was wide enough to deny the claim.

For Canadian leaders the picture is sharper still. A 2025 IBC and Angus Reid survey found that only 22% of Canadian small and mid-sized organizations carry any form of cyber insurance, and just 12% hold a dedicated stand-alone policy. Meanwhile 72% of those same respondents said AI is making cyber risk harder to defend against. So most organizations are underinsured, increasingly exposed, and walking into a market that is getting pickier about who it covers and how much it pays when something goes wrong.

What does this mean for the work?

The renewal conversation is no longer a procurement exercise. It’s a controls conversation. And the questions worth bringing to it aren’t mostly about price. They’re about proof.

Can you demonstrate, today, that the controls you attested to last year are deployed the way you described? Not in theory, in the policy document, but in the actual environment, on the actual endpoints, for the actual accounts. If a claims adjuster walked in tomorrow and pulled the configuration of your MFA, your EDR coverage, your backup retention and isolation, and your admin account hygiene, would the picture match the application?

Some of the ambiguity is on the application itself. Older policies asked broad questions (“are all accounts protected by MFA?”) that were difficult to answer cleanly in a real environment with service accounts, legacy systems, and vendor exceptions. Newer applications are getting more specific (“all email accounts protected by MFA”), which helps, but the language still varies policy to policy. Part of the work at renewal is reading carefully enough to know what you’re actually attesting to.

Where would an adjuster find a gap? Because there is often a gap. The acquired entity that hasn’t been fully integrated. The line-of-business system whose vendor still doesn’t support modern MFA. The shared service account everyone forgot about. The backup job that’s been failing silently for six weeks. These are the gaps that don’t matter on a normal Tuesday and matter enormously on the Tuesday something goes wrong.

A useful exercise before your next renewal: take last year’s application and walk through the attested controls with your IT team or partner. For the ones that are clearly worded, ask for evidence (a configuration export, a coverage report, a screenshot) that they’re deployed the way the application described. For the ones that are ambiguous, get aligned on how you’re interpreting the question before you sign the next attestation. The deltas you find are the deltas the adjuster would find.

The policy you think you have is the one that pays if those two pictures match.

The trouble is, buying the tool isn’t the job. Running it is.

We’ve watched this pattern play out in IT security and backup for twenty-five years. An organization licenses the right products, the dashboards turn green, and everyone moves on. Then something goes wrong, and the gap between “we have the tool” and “the tool actually did its job” turns out to be wider than anyone realized.

Backup is the cleanest example. Industry surveys consistently find that a meaningful share of organizations who go to restore from backup don’t get all their data back. The [2024 State of the Backup Survey](https://drj.com/industry_news/2024-state-of-the-backup-survey-says-security-incidents-and-data-loss-on-the-rise/) found that only 42% of organizations who experienced data loss recovered all of their data on restore. These are organizations with backup systems in place. The tools were running. The jobs were completing. The restore still came up short. Somebody, somewhere, looked at a green dashboard last Tuesday and told themselves things were fine.

The tool isn’t the thing. The human running it is.

At Smart Dolphins we run a centralized services team whose whole job is making the tech, security, and backup stack do what it claims to do. We human-verify backup jobs daily. Not “the dashboard says green,” but a person confirming the job ran, the data is recoverable, and yesterday’s quiet failure isn’t sitting there waiting to ruin somebody’s week. That sounds unglamorous because it is. It’s also the part of the work that determines whether the protection you’re trusting in is real on the day you actually need it.

The same logic applies to patching, to endpoint protection, to spam filtering, to identity and access. Each of those tools has a dashboard. Each dashboard can be green while something underneath is quietly broken or misconfigured or drifting out of policy. The work of catching that drift isn’t done by the tool. It’s done by someone whose job is to look, verify, tune, and fix.

So when you’re thinking about your own setup, whether that’s your MSP, your internal IT team, or the security stack you’ve been told is handled, the question worth sitting with isn’t which tools you have. It’s who’s watching them, tuning them, and verifying them on a Tuesday afternoon when nothing is on fire. That Tuesday afternoon work is what determines whether the tool is an asset or an expensive illusion.

Buying tools is easy. Running them is the actual job, and it always has been.

That’s the kind of thing some leaders say when they’re thinking about their IT setup. No crisis. No systems on fire. Just a quiet, hard uncertainty that a lot of leaders share but rarely say out loud. And there’s one simple question that can reframe the thinking productively:

“What percentage of the work your team or IT provider does for you is reactive versus proactive?”

One question. But the answer reshapes how you think about the effectiveness of your IT budget, and it gives you a sentence you can take straight to your board or leadership team: “Right now, 70% of our IT spend is keeping things from falling apart. 30% is building stability, capacity, and new capability. Here’s our plan to shift that over the next twelve months.” Decision-makers understand that framing instantly.

The distinction that matters

Reactive work is everything that happens after something breaks: tickets, outages, emergency calls. It’s necessary, but it’s pure expense. You’re paying to get back to where you were before the problem happened.

Proactive work is the other side. Most people assume that means patching, backups, and hardware planning — the defensive layer that prevents future fires. That matters. But usually the bigger value comes from aligning technology with where your organization is heading, redesigning a workflow that’s costing your staff hours every week, surfacing opportunities you didn’t know were available because you’ve been too deep in the day-to-day to look up.

Proactive work that only prevents problems is optimization. Proactive work that opens up new capacity or improves how your organization operates is opportunity. If your IT function is only doing the first kind, you’re leaving a lot on the table.

What the answer tells you

If the work is mostly reactive, that doesn’t necessarily mean your team or provider is failing. Some organizations have years of accumulated technical decisions creating a heavy reactive load, and the environment needs to be stabilized before proactive efforts can gain traction. But now you know, and knowing gives you a starting point: what would it take to shift the ratio? What proactive work has been deferred? Where should you invest intentionally instead of absorbing whatever comes?

If the answer is mostly proactive, ask whether that work maps to your actual strategic priorities or just a standard checklist applied regardless of context. If your team or provider can’t draw that line, the work needs to be revisited.

Turning the ratio into a tool

Here’s what this can look like in practice. Imagine an organization sitting at roughly 80/20, reactive to proactive. That’s not unusual. After about eighteen months of intentional work — stabilizing the environment, retiring old systems, putting monitoring in place — an organization like that could realistically get somewhere between 50/50 and 20/80. Total monthly IT spend might go up significantly, but the number of disruptions staff deal with could drop dramatically. In practical terms, that often looks like an administrative team reclaiming dozens of hours a month that had been eaten by workarounds, manual processes, and waiting on broken systems.

That recovered capacity is where the real story is. It’s what lets a team finally launch the program expansion they’ve been deferring, or redirect staff time toward work that actually moves the mission forward.

That’s a fundamentally different budget conversation than “we need more money for IT.”

Knowing the ratio also creates accountability in a healthy way. If you agree together that the goal is to shift from 70% reactive to 50% reactive over the next year, you’ve got something concrete to track. Not as a gotcha, but as a shared objective — something both sides can look at quarterly and make decisions around together.

You don’t need a fancy assessment to start. Just ask this fundamental question. See what your team or provider says. If they can answer clearly and specifically, that’s a good sign regardless of the ratio. If they can’t, that tells you something too.

AI use is already happening in most organizations, whether it’s formally approved or not. Without clear expectations, employees make individual judgment calls about what data to use, how outputs are applied, and whether results are reviewed. 

This creates real challenges: 

• Data risk from sensitive information entered into public tools  

• Inconsistent outputs and client experience  

• Lack of accountability for outcomes  

• Duplicated effort across teams  

The result is increased risk, wasted time, and uneven return on AI investment. 

Unstructured AI use also creates opportunity cost. Teams work in isolation, repeat mistakes, and fail to scale what works across the organization. 

AI policy is a key step in moving from ad hoc experimentation to consistent, reliable use. 

Pillar 1: Make AI Use Visible 

Understanding Shadow AI 

Shadow AI refers to AI use that happens informally, without oversight or defined expectations. It often emerges because employees are trying to work more efficiently without clear guidance. 

This can compromise sensitive information or degrade the client experience. 

Common Risky Use Cases 

Examples include: 

• Publishing client-facing content generated by AI without proper review  

• Summarizing internal reports using public tools  

• Entering internal or client data into AI tools without understanding how that data is handled 

Creating Visibility into AI Usage 

The first step in governing AI is visibility. Leaders should acknowledge that AI is already part of daily work and take a simple inventory of where and how it is currently being used. 

This is often done through an internal survey. The goal is to surface existing use cases and identify where guidance is needed. 

Building Guidelines for Safe AI Use 

Organizations may choose to approve specific tools or define which use cases are appropriate in different environments. 

The goal is to allow teams to experiment safely while ensuring sensitive workflows are handled within secure tools. 

Encouraging Shared Learning and Transparency 

Creating a shared space for AI learnings helps teams build capability together. For example, a dedicated Teams channel can be used to share workflows, prompts, and lessons learned. 

This allows organizations to monitor usage patterns while helping teams learn from each other. 

Reducing Risk Through Transparency 

Shadow AI creates risk when usage is hidden. Encouraging transparency reduces that risk and helps organizations scale AI use more effectively. 

Pillar 2: Ownership and Accountability 

One of the biggest gaps in AI governance is ownership. When no one owns AI, decisions become fragmented and risks go unnoticed. 

Most organizations benefit from defining two roles: 

• AI Owner: Oversees usage patterns and ensures governance is addressed at a leadership level  

• AI Adoption Lead: Helps teams apply AI in real workflows and supports ongoing adoption  

These responsibilities can sit within existing roles and typically require only 1–2 hours per week. 

What matters is clear ownership and a defined path for support and escalation. 

Pillar 3: AI Principles 

Draw Principles from Your Values 

AI principles should be grounded in company values and focused on behavior, not technology. They should be simple, practical, and easy to apply. 

Examples of Practical AI Principles 

• AI-generated work is reviewed before being shared externally  

• AI supports decision-making but does not replace accountability  

• AI is used to improve efficiency without sacrificing quality  

• AI outputs are reviewed with the same scrutiny as a new employee’s work  

Guiding Decisions in New Situations 

AI policies cannot cover every scenario. Principles help teams make decisions in new or evolving situations while staying aligned with company expectations. 

Pillar 4: AI Policy Contents 

Positioning the Policy as a Practical Guide 

An AI policy should function as a practical guide, not a legal document. It should be clear, concise, and grounded in real workflows. 

Core Elements of an AI Policy 

At a minimum, an AI policy should include: 

• The purpose of AI within the organization  

• AI principles  

• Approved and prohibited uses  

• Expectations for review and oversight  

• Ownership and governance structure  

• How and when the policy will be updated 

Keeping Policies Usable and Relevant 

Policies that are too complex or disconnected from daily work will be ignored. Clarity and usability should be the priority. 

From Control to Capability 

AI is becoming a core business capability, similar to email or cloud platforms. Organizations that succeed do not rely on informal experimentation. They build light, intentional structure through visibility, ownership, shared principles, and practical policy. 

The goal of AI governance is confidence, not restriction. When expectations are clear, teams can use AI effectively, responsibly, and with less risk.

Not directly, usually. It shows up sideways, in conversations at industry events or over coffee. “So, 25 years… what’s next?” The question carries a set of assumptions. Guy in his 50s, been at it a while, business is doing well. The script says this is where you start thinking about an exit. Cash out. Slow down. Enjoy the fruits.

I get it. And I’ve watched a lot of my peers follow that script. Some were tired. Some hit a ceiling they didn’t want to push through. Some just saw a good offer and took it. I don’t judge any of that. Everyone’s working with their own set of circumstances, and selling a business you built is a legitimate choice that can change your life in meaningful ways.

But it’s not my choice. At least not right now. And I think the reasons why might be worth sharing.

There’s a common philosophy in business: build it like you’re going to sell it. Get your systems tight, your team strong, your financials clean. Make the thing attractive to a buyer. Here’s what’s funny about that. It’s the same logic as fixing up your house to put it on the market. You finally renovate the kitchen, paint the trim, stage everything just right. Then you walk through it and think… why am I selling this place? It’s never been better.

I think the same thing applies to a business. If you do the hard work of building something that doesn’t revolve around you, that runs well, that creates value for the people in it, you’ve built something worth keeping. The very things that make it sellable are the things that make it worth owning and the things that make it worth continuing.

And I think that’s where some business owners get stuck. It’s not that owning a business is inherently draining. It’s that they built one that needs them at the centre of everything. Every decision, every client relationship, every fire. That’s exhausting after 15 or 20 years. Of course you want to escape that.

But the escape impulse might be a symptom, not a solution. Selling doesn’t fix the pattern. It just ends it.

I’ve tried, imperfectly and over a long time, to build Smart Dolphins so it doesn’t need me in the middle of things. Not because I was planning to leave, but because I think that’s just a better business. It’s better for the team. It’s better for clients. It’s better for me. I get to choose where I put my energy instead of the business making that choice for me.

So when I think about what I actually want, it’s not an exit. It’s flexibility. Working from somewhere warm for a couple months in the winter. Spending my time on things that matter most rather than whatever’s on fire. Still learning, still being challenged by new problems.

That probably sounds simple, but getting there has been the work of 25 years. And I’m still working at it!

Here’s what I’ve come to believe, though. A business built with intention can actually be one of the most freeing things in your life. You have a place to be productive and creative. You’re connected to people you care about. You have problems worth solving. What does selling give you? A blank calendar. Some of the people I know who sold eventually went looking for something similar to fill it.

I’ve watched peers cash out, enjoy life for six months or a year, and then start circling back. Some started consulting. Some got into private equity. Some started new businesses in the same or adjacent industry they just left. Which always makes me wonder: what if they’d just kept building what they originally built?

I’ll be honest. There have been hard stretches where I wondered if I should move on. Big challenges that tested me. Times where I genuinely wasn’t sure I could lead the next version of this company. A growing business asks things of you that you haven’t learned yet, and that gap can feel pretty permanent when you’re in it.

But I think most of those ceilings are ones we build for ourselves. We get comfortable. We mistake familiarity for limitation. The skills and growth required to lead a bigger, more complex business aren’t genetic. They’re learnable. The question is whether you’re willing to do the uncomfortable thing.

And look, when you’ve been at it this long and things are going well, coasting is tempting. Just protect what you’ve built. Stay comfortable. But the stretches I look back on most fondly aren’t the easy ones. They’re the ones that cost me sleep. The ones where I wasn’t sure it would work out. Doing hard things doesn’t feel meaningful while you’re in it. It does after.

Writing 25 insights from 25 years has a feeling of finality to it. Like I’m packaging up the lessons and putting a bow on things. But I might only be halfway through. There’s a lot of runway ahead, and I have a belief that some of the most interesting chapters are still ahead.

I’m not naive about that. The world changes. Circumstances change. Maybe something happens that makes selling the right call. I’m open to that possibility. But I’m not looking for an exit. I’m not building toward a finish line. I’m building toward more of what I already love: a great team, work that matters for clients that matter, interesting problems, and the room to keep evolving how I show up in all of it.

So no, I’m not retiring. I’m not done.

Can’t wait to write 50 insights from 50 years.

What’s this 25/25 stuff about?: 25 YEARS, 25 INSIGHTS – Reflections on Growth, Leadership and Resilience | Smart Dolphins IT Solutions Inc.