What does a healthy MSP relationship look like day to day?

It runs on structure most clients never see: a daily health check that reviews servers, backups, and overnight alerts before your workday starts, a monthly service review, and a documented change process. Problems get caught while they are still a line item, not a production outage.

How often should my managed IT provider meet with us?

At least monthly, in a structured service delivery review that covers ticket volumes, recurring issues, risks, and what is coming next. If you are hearing bad news for the first time in that monthly meeting, your provider failed a step earlier. Serious issues should reach you the same day they happen.

What is an IT change management process and why does it matter?

It is an agreed set of rules for how any update, patch, or configuration change gets made in your environment. Nothing changes without you knowing in advance, and every change has a scheduled window, a documented reason, and a rollback plan. It turns “IT broke something” into “we agreed on this window, here is the plan.”

How can I tell if my IT provider is actually proactive?

Ask them to walk you through what they did for you last Tuesday, not last quarter. A provider with real structure can name the morning checks that ran, the alerts reviewed, the changes scheduled, and the tickets closed. A reactive provider will only describe their general approach.

Artemy | BALANCED+

What Clients Never See: The Structure Behind a Healthy MSP Relationship

Posted on July 14, 2026 by Artemy

A few months ago, in a monthly review meeting, a client executive stopped me at an item on our risk list. It was a storage volume trending toward capacity, flagged and scheduled for remediation. He read it, looked up, and asked: “So what would have happened if you had not caught this?”

The honest answer was uncomfortable. You would have found out in about three weeks, probably during your busiest production window, and this would have been a very different meeting.

That question has stayed with me, because it gets at something most businesses quietly worry about but rarely say out loud: is my IT provider actually watching, or do they only show up when something breaks?

I work at a managed service provider. I spend most of my week embedded at client sites, and I have sat on both sides of that worry. So I want to open the hood and show what a healthy MSP relationship actually looks like from the inside. Not the version on the website. The version that happens at 7:30 in the morning when nobody is watching.

The morning nobody sees

Every working day starts the same way for me: a health check that runs before the client’s day does. Servers. Databases. Backup jobs from the night before. Network hardware. The phone system. Monitoring alerts that fired overnight.

It takes maybe forty minutes. Most days, nothing is wrong. And that is exactly the point.

Here is what years of doing this have taught me: serious problems almost never arrive out of nowhere. They announce themselves quietly, days in advance, in ways that are easy to miss if nobody is listening. A backup job that took twice as long as usual. A disk creeping toward full. A server that rebooted itself at 2 AM and came back fine, this time.

That storage volume from the opening? It was caught on a Tuesday morning during a routine check, when it was still just a line item on a spreadsheet. The alternative version of that story is a production floor standing still while everyone scrambles to figure out why orders stopped flowing. Same root cause. Completely different day.

The daily check is boring. I will not pretend otherwise. But boring, done every single day, is what prevention actually looks like. There is no dramatic version of catching a problem early. That is the whole idea.

A monthly meeting with no surprises

Once a month, I sit down with the client’s leadership for what we call a Service Delivery Review. On paper it is a status meeting: what happened, what is at risk, what is coming next. In practice it is something closer to a trust exercise.

Because here is the thing about these meetings. They are only comfortable if you have nothing to hide. Ticket volumes go on the table. Recurring issues go on the table. Things we got wrong go on the table too. If we misjudged a maintenance window or a fix took longer than it should have, the client hears it from me, in that room, with context.

I have come to believe the review is not really for the MSP at all. It is the client’s meeting. And there is one rule I hold myself to: if the client is hearing bad news for the first time in a monthly review, we already failed a step earlier. Bad news should travel fast, the same day it happens. The monthly meeting is where we look at patterns, make decisions, and plan ahead.

Good to know:

There is a quieter benefit to the cadence itself. A client who hears from their provider every month, in a structured way, never has to sit and wonder whether anyone is paying attention. That wondering is corrosive. It is where distrust starts, long before anything actually breaks.

Nothing changes without you knowing

One of the most valuable documents in any client relationship is also one of the least glamorous: a written change management process, approved by the client, that governs how anything in their environment gets modified.

Change management process

A change management process is an agreed set of rules for how any update, patch, or configuration change gets made in your IT environment. No change happens without the client knowing in advance, and every change has a scheduled window, a documented reason, and a rollback plan in case it goes sideways.

I will be honest about how this feels day to day. Process feels slow, right up until the first time it saves you. Then it feels like the only sane way to work.

But the real value is not technical. It is emotional. Without a change process, every hiccup turns into “IT did something and now this is broken,” which is a terrible sentence for everyone involved. With one, the conversation becomes “we agreed on this window, here is what we planned, here is what we are doing about it.” Same event. Entirely different relationship.

When things break anyway

I want to be straight about something, because this is where a lot of MSP writing gets dishonest. Structure does not prevent every incident. Hardware fails. Software has bugs. I have been on-site at 7:40 in the morning doing a cold restart of a server after a night nobody enjoyed. Anyone in this industry who tells you outages are a thing of the past is selling something.

What structure changes is everything that happens next.

From the client’s chair, a well-handled incident has a recognizable shape. Someone acknowledges the problem fast. Updates keep coming while things are still broken, even when the update is “we are still working on it, here is what we know so far.” And afterward, there is a written explanation of the root cause in plain English. Not jargon. Not a wall of log excerpts. A version the business owner can read and actually understand, because it happened to their business and they deserve to know why.

I have written those explanations after long nights, and I can tell you the temptation to hide behind technical language is real. Resist it. In my experience, clients do not lose trust because something broke. They lose trust when nobody can explain why, or when the same thing breaks twice and nobody connected the dots.

Being heard is a process, not a personality

Every MSP says some version of “we listen to our clients” or “we are proactive, not reactive.” I have said those words myself. But at some point I realized that being heard is not a soft skill. It is an output. It is what falls out of the structure when the structure is real.

Think about what the pieces add up to. The daily check means someone is watching your environment before you wake up. The monthly review means you are never in the dark about your own systems. The change process means nothing happens behind your back. The plain-English incident writeup means even the worst days end with understanding instead of confusion.

None of those pieces, individually, is impressive. Together, they are the answer to the fear I opened with. A charming account manager with no system behind them will eventually miss something that matters. A solid system makes even an ordinary Tuesday feel like someone has your back. Ideally you get both. But if I had to choose, I would take the system every time, because the system does not have bad weeks.

The question worth asking

If you work with an IT provider today, or you are evaluating one, here is a simple test. Do not ask about their tools or their certifications. Ask this instead: “Walk me through what you did for us last Tuesday.” Not last quarter. Last Tuesday.

A provider with real structure can answer in detail: the morning checks that ran, the alerts reviewed, the changes scheduled, the tickets closed. A reactive provider will talk about their general approach, because on any given Tuesday where nothing broke, they were not thinking about you at all.

And that brings me back to that question from the review meeting. “What would have happened if you had not caught this?” It is a fair question, and I never mind answering it. But the best measure of a healthy MSP relationship is that with the right structure in place, it is a question you rarely have to ask.

This is what our managed IT services are built around: daily monitoring, monthly service reviews, and a change process that keeps you in the loop. If you are wondering whether your current provider is watching or just waiting for the phone to ring, that is a conversation worth having. Get in touch and we will walk you through what our week looks like.

Human Error Remains the Biggest Cybersecurity Risk

Posted on July 3, 2026July 3, 2026 by Artemy

You can spend six figures on firewalls, endpoint protection, and round-the-clock monitoring and still get breached because one employee granted access to someone they believed was IT support. That is not a hypothetical. It is the most common way Canadian mid-market businesses get compromised, and in most cases the security tools were working exactly as designed when it happened.

This post covers why human error is still the leading cause of cyber incidents, the social engineering threats your organization faces today, and the practical steps that actually lower the risk.

Human error remains the biggest cybersecurity risk because attackers have shifted their focus from breaking technology to manipulating people, and people are far easier to fool than modern security tools are to defeat. Social engineering, from phishing emails to fake IT-support requests for remote access, along with weak or reused passwords, bypasses technical controls by targeting the person holding the keys. The organizations that stay secure treat their staff as part of the defence, pairing layered technology with continuous training so a single mistake does not turn into a breach.

Human Error (in Cybersecurity)

In cybersecurity, human error is any unintentional action, or failure to act, by a user that gives an attacker an opening: granting remote access to an impostor, clicking a malicious link, reusing a password, or sending sensitive data to the wrong recipient. It is distinct from malicious insider activity because there is no intent to cause harm, which is exactly why it is so hard to defend against with technology alone.

Why do attackers target people instead of systems?

Because it works, and it is cheaper. A modern security platform that is patched and configured correctly is genuinely hard to break. A distracted employee at 4:45 on a Friday is not. Rather than spend weeks hunting for a software vulnerability, attackers reach people directly by email, phone, chat, or a remote-support tool, ask them to approve a request or grant access, and let normal human behaviour do the rest.

68%

of data breaches involved a human element such as error, misuse, or social engineering (Verizon 2024 Data Breach Investigations Report)

We see this pattern directly. When we run a baseline social engineering test for a new GTA client before any training, the number of staff who engage with a convincing request commonly lands between 20 and 30 percent. These are not careless people. They are busy staff who have never been shown what a modern attack actually looks like, and that gap is what attackers monetize. According to the Verizon 2024 Data Breach Investigations Report, the human element is a factor in roughly two-thirds of all breaches, a figure that has barely moved despite years of improving security technology.

What are the most common social engineering threats?

Social engineering is the common thread behind most human-driven incidents, whether it arrives as a phishing email, a fake IT-support request, or a phone call. It works by getting a legitimate user to act on the attacker’s behalf, which is why it slips past tools built to stop malicious code. Weak passwords then compound the problem by turning one successful trick into access across multiple systems.

Social Engineering

Social engineering is any attack that manipulates a person into granting access, revealing information, or taking an action that helps the attacker, rather than exploiting a technical flaw. It spans phishing emails, fraudulent phone calls, text messages, and impersonation over chat or remote-support tools. Because it targets human trust instead of software, it routinely bypasses technical defences.

Threat	How it exploits people	First line of defence
Phishing	Fake emails, websites, and messages that impersonate trusted brands or colleagues to steal credentials or deliver malware	User training plus email filtering and MFA
IT-support impersonation	Attackers pose as internal IT or a trusted vendor over chat or remote-support tools and request access to a workstation	Verify every unexpected access request through a known channel
Weak passwords	Reused, predictable, or shared passwords let one leaked credential unlock multiple accounts	A password manager, enforced complexity, and MFA

A single successful trick often becomes the foothold for a wider campaign, which is why we treat social engineering defence as the foundation rather than one item on a checklist.

Warning:

Attackers increasingly use AI to write flawless, personalized messages, so the old advice to “watch for spelling mistakes” no longer holds. A message can be grammatically perfect, reference a real project, and still be fraudulent. Verification habits matter more than spotting typos.

How do attackers impersonate IT support?

A fast-growing social engineering tactic skips email entirely: the attacker contacts a user directly through a chat or remote-support tool, claims to be from IT or a trusted vendor, and asks for remote access to fix an urgent problem. The channel is what makes it effective. A message in Microsoft Teams or a session request through a tool like ScreenConnect feels far more legitimate than a cold email, so the usual phishing instincts never fire.

Once a user grants access, the attack moves fast. An impostor with a live remote session can install malware, copy sensitive data, and disconnect within minutes, often before anyone realizes the “support technician” was never from IT. Because none of this touches the email gateway, email-based phishing training does nothing to stop it. This is exactly why awareness has to extend beyond the inbox to every channel a user can be reached on.

Warning:

Treat any unexpected request for remote access as hostile until proven otherwise, whether it arrives by email, phone, Microsoft Teams, or a remote-support tool such as ScreenConnect. Verify it through a known IT contact or your ticketing system before granting access. A real technician will never object to being verified.

Why isn’t security technology enough on its own?

Because every technical control still has a human in the loop, and that person can be persuaded to open the door. Firewalls, endpoint detection, and multi-factor authentication all raise the cost of an attack, but a user who approves a fraudulent MFA prompt or hands remote control to a fake technician has just walked the attacker past those defences. Technology narrows the attack surface; it does not remove the person standing in the middle of it.

99.9%

of automated account-compromise attacks are blocked by enabling multi-factor authentication (Microsoft)

That does not make the technology optional. Multi-factor authentication alone blocks the overwhelming majority of automated account attacks, according to Microsoft. The point is that controls and people reinforce each other. Layered technology catches the mistakes training misses, and trained users catch the attacks that slip past the tools.

Move your organization to phishing-resistant MFA (hardware keys or passkeys) for administrators and finance staff first. These accounts are the highest-value targets, and app-based push approvals can still be defeated by MFA fatigue attacks where a user taps “approve” just to stop the notifications.

How do you build a security-aware culture?

You build a security-aware culture by making safe behaviour routine and easy, not by running a once-a-year training video and hoping it sticks. The goal is an organization where staff recognize common attacks across every channel, follow simple verification habits, and feel safe reporting a mistake immediately. The following steps are the ones we put in place for clients, in order of impact.

Train regularly, in short sessions: Replace the annual marathon with brief, frequent refreshers covering email, phone, and chat-based attacks. People retain more from ten focused minutes each month than from a single long session they forget by lunch.

Verify every remote-access request: Teach staff that no one approves remote control of their workstation from an unexpected message or call, no matter how urgent it sounds. Confirm through a known IT contact or a ticket first, regardless of the channel it came through.

Run social engineering simulations: Send realistic phishing tests and, where possible, simulate impersonation attempts, then measure engagement and report rates. Simulations turn an abstract risk into a concrete, improvable number and show staff what a real attack feels like in a safe setting.

Enforce strong passwords and MFA: Require a password manager, block reused and breached passwords, and turn on multi-factor authentication everywhere it is available, starting with email and privileged accounts.

Make reporting easy and blameless: Give staff a one-click way to report a suspicious message or call, and thank them when they do, even for false alarms. The faster a real attack is reported, the smaller the damage.

This works. Across the clients where we run continuous simulations and short monthly training, we typically see engagement with test attacks fall from that 20 to 30 percent baseline into the single digits within a few cycles, and report rates climb at the same time. The cost of that program is trivial next to the alternative. IBM puts the global average cost of a data breach at US$4.88 million in 2024.

US$4.88M

average total cost of a data breach in 2024, the highest on record (IBM Cost of a Data Breach Report 2024)

The bottom line

The strongest cybersecurity strategy combines advanced security technology with continuous employee education. Technology alone cannot stop social engineering that convinces a person to open the door, whether by email, phone, or a remote-support tool, and awareness alone cannot catch what slips through. Reducing human error is the highest-leverage move most organizations can make to lower the risk of a successful attack and strengthen their overall security posture.

BALANCED+ is a Fortinet Authorized Partner, and our security engineers hold Fortinet NSE certifications, but we tell every client the same thing: the technology is only half the job. Our managed cybersecurity team runs social engineering testing and awareness training alongside the firewalls, monitoring, and MFA, so your people become a layer of defence rather than the weakest link. If you want to see where your staff stand today, a baseline social engineering assessment is a low-effort place to start.

Sources

2024 Data Breach Investigations Report, Verizon, 2024.
One simple action you can take to prevent 99.9 percent of attacks on your accounts, Microsoft, 2019.
Cost of a Data Breach Report 2024, IBM, 2024.

How a Missing Database Index Turned a 50ms Query Into a 10-Second Problem

Posted on June 22, 2026June 30, 2026 by Artemy

Performance problems do not always arrive with an alert or a failed deployment. Sometimes they show up quietly, during routine development, on a page that works perfectly but takes far longer to load than it should. That is exactly how this one surfaced: while testing a new feature, one page was noticeably slow. No errors, no failures, just a response time that did not match the size of the data being returned.

This post walks through how we diagnosed it, why SQL Server made the choice it did, and the index design that fixed it. The headline result: a single index took the query from roughly 10 seconds down to about 50 milliseconds, with no infrastructure changes and no application rewrite.

A slow query is usually a clue, not a verdict on your hardware. In this case SQL Server was running a full table scan because no index supported the query’s filter and sort. One well-designed composite index replaced the scan with an index seek and cut execution time from about 10 seconds to about 50 milliseconds, roughly a 200x improvement, without touching the server or the application code.

Database Index

A database index is a separate, ordered data structure that lets the database engine locate rows without reading the entire table. It works like the index at the back of a book: instead of scanning every page to find a topic, the engine jumps straight to the right location. A well-matched index turns a full table scan into a targeted seek, which is the difference between reading thousands of rows and reading a handful.

Step 1: Isolate Where the Time Actually Goes

Before touching the database, we confirmed where the time was being spent. The application server was not under load, CPU and memory looked normal, and there was no sign of an infrastructure bottleneck. Breaking the request down by stage made the problem obvious: almost all of the response time was spent waiting on a single database query to return. Everything else, application logic, serialization, and network, was negligible by comparison.

This step matters because a slow page is easy to misread as an underpowered server. Here, more hardware would have done nothing. The query itself was the bottleneck, so that is where the work belonged.

Step 2: Read the Execution Plan

The query was not complex. It filtered on a couple of columns, applied a sort, and returned a modest result set. To understand why it took 10 seconds, we looked at the SQL Server execution plan, which shows the strategy the optimizer chose for retrieving the data. The same query can be executed in many different ways, and SQL Server picks the plan it estimates to be cheapest based on the available indexes and its statistics.

The plan showed a clustered index scan, effectively a full table scan. Instead of jumping straight to the rows it needed, SQL Server was reading a large portion of the table and discarding everything that did not match. A few other signals lined up with that diagnosis:

A thick arrow leaving the scan operator, meaning a large number of rows were read into the pipeline before any filtering.
A Sort operator to satisfy the ordering, which is expensive and memory-hungry on large inputs.
A green missing-index recommendation at the top of the plan, SQL Server’s own hint that it had no efficient path to the data.

Good to know:

The query was not wrong. It returned correct results every time. The database simply had no efficient route to the rows, so it fell back to the only reliable option it had: read everything, then filter. That distinction matters, because the fix is an indexing decision, not a code bug.

Step 3: The Query and Why the Scan Happened

The query looked similar to this:

SELECT *
FROM CustomerOrders
WHERE TenantId = @TenantId
  AND Status = 'Active'
ORDER BY CreatedDate DESC;

At a glance it looks harmless: filter on two columns, sort the result. The problem was what the table offered to support that pattern, which was nothing useful. There was no index that led with TenantId and Status, so SQL Server could not seek directly to the matching rows. On a small table this is invisible. As the table grows, the cost of scanning every row on every execution grows with it, which is why this query performed fine early in the project and degraded over time as data accumulated.

Two more details made the scan worse than a simple filter. First, ORDER BY CreatedDate DESC forced a separate sort step, because the data was not retrieved in that order. Second, SELECT * pulled every column, which has consequences for the fix described below.

Step 4: Design the Right Index, Not Just an Index

It is tempting to read the missing-index hint, create exactly what it suggests, and move on. The hint is a starting point, not a finished design. Per Microsoft’s index design guidance, a good index for this query follows a clear order of columns:

Equality predicates first: TenantId and Status are matched with =, so they lead the key. This is what lets SQL Server perform an index seek straight to the relevant rows instead of scanning.

The sort column next: adding CreatedDate DESC to the key means rows come out of the index already in the requested order, which removes the expensive Sort operator entirely.

That gives us:

CREATE INDEX IX_CustomerOrders_TenantId_Status_CreatedDate
ON CustomerOrders (TenantId, Status, CreatedDate DESC);

This is stronger than indexing only (TenantId, Status). That narrower index still helps SQL Server find the rows, but it leaves the ORDER BY unsupported, so the engine would still add a Sort. Including the sort column in key order avoids that work altogether.

Order your composite index keys as equality columns first, then the sort column, then range columns. Getting that sequence right is what lets a single index satisfy both the WHERE filter and the ORDER BY in one seek, with no separate sort step.

The SELECT * Problem and Covering Indexes

There is one more consideration. Because the query uses SELECT *, the index above still does not contain every column the query returns. SQL Server would seek the index to find matching rows, then perform a key lookup back to the clustered index for each row to fetch the remaining columns. On a large result set, thousands of key lookups can quietly undo much of the benefit. There are two clean ways to handle it:

Return only the columns you need instead of SELECT *, which is good practice regardless of indexing.
Add the required columns as included columns so the index can satisfy the whole query on its own, known as a covering index.

CREATE INDEX IX_CustomerOrders_TenantId_Status_CreatedDate
ON CustomerOrders (TenantId, Status, CreatedDate DESC)
INCLUDE (OrderTotal, CustomerName);  -- the columns the page actually displays

Included columns live at the leaf level of the index and are not part of the key, so they support the lookup without bloating the seek. The right choice depends on how many columns the page genuinely needs. The point is to make a deliberate decision rather than accept the default hint.

Step 5: Verify the Fix With Numbers, Not Vibes

After creating the index, we re-ran the query and re-examined the plan. The clustered index scan was replaced by an index seek, and the Sort operator was gone. To confirm it with hard numbers rather than wall-clock timing alone, we used the statistics output:

SET STATISTICS IO, TIME ON;
-- re-run the query, then compare logical reads before and after

Logical reads dropped dramatically, which is the real measure of how much work a query does and is far more stable than a stopwatch on a busy server. The end-to-end results:

Metric	Before (no index)	After (composite index)
Query execution time	~10 seconds	~50 milliseconds
Data access method	Clustered index scan	Index seek
Sort operator	Present	Eliminated
Logical reads	High	A small fraction
Page response	Noticeable delay	Near-instant

~200x

Faster query execution after adding one index: from approximately 10 seconds to approximately 50 milliseconds, measured in a BALANCED+ engagement

And the change required none of the things teams usually reach for first: no infrastructure upgrades, no additional servers, no application rewrite, and no changes to business logic. A single, well-designed index delivered the entire improvement.

Why Indexing Is Worth Understanding, and Not Overdoing

Indexes are one of the most effective tools for database performance, but more indexes is not the goal. Every index carries a cost: it must be maintained on every insert, update, and delete, and it consumes storage. Over-indexing a write-heavy table can hurt as much as under-indexing a read-heavy one.

Warning:

Do not treat SQL Server’s missing-index recommendations as instructions. They identify candidates based on a single query in isolation, with no awareness of your write patterns or existing indexes. Blindly creating every suggested index leads to duplicate and overlapping indexes that slow down writes and bloat storage. Use them as input to a deliberate design, not a to-do list.

Effective indexing comes from understanding how the application actually queries the data: which columns are filtered with equality versus ranges, what ordering queries request, which columns are returned often enough to justify covering them, and how write-heavy the table is. Query patterns also drift over time as features get added, reporting requirements change, and data volumes climb. Indexes that were adequate at launch can quietly become liabilities at scale, which is exactly why periodic performance reviews belong alongside new feature work, not after something breaks.

The Business Impact of a 10-Second Query

A 10-second delay can look trivial in isolation. Multiplied across hundreds or thousands of requests a day, it is not. Slow pages interrupt workflows, reduce productivity, and erode user confidence in a system that feels unresponsive. Reducing this query from 10 seconds to 50 milliseconds changed the experience of the whole page without any architectural change. That is the kind of leverage well-targeted database work offers: small, surgical, and disproportionately impactful.

Lessons Learned

Measure before you optimize. Confirm where the time actually goes before assuming it is the server, the code, or the network.
Read the execution plan. It tells you exactly how SQL Server runs your query: scan versus seek, sorts, lookups, and where the cost lives.
Design indexes, do not just create them. Equality columns first, then sort columns, and decide deliberately about covering the query.
Data growth exposes problems that were invisible early on. What scaled fine at launch may not scale at volume.
Review performance proactively. The best time to find this is during a routine review, not during an outage.

Sometimes the most impactful optimization is simply helping the database find data it already has more efficiently. Here, one composite index reduced execution time from seconds to milliseconds and delivered a meaningfully better experience for everyone using the application, with zero infrastructure spend. That is the kind of improvement every development team likes to find.

Proactive performance reviews like this are part of how we keep mid-market systems healthy before slowdowns turn into outages. If your team is seeing pages that feel slower than the data warrants, our managed IT and application support practice can help diagnose and resolve it. Get in touch with BALANCED+ to talk through a performance review.

Frequently Asked Questions

What is the difference between an index seek and an index scan?

An index seek uses the index structure to navigate directly to the rows that match a query, reading only what it needs. An index scan reads through the entire index or table and filters afterward. Seeks are typically far cheaper on large tables, and moving from a scan to a seek is one of the most common high-impact query optimizations.

Why was the query slow if it returned correct results?

Correctness and performance are separate concerns. The query returned the right rows every time, but with no supporting index SQL Server had to scan a large portion of the table and sort the results on every execution. Correct results with poor performance almost always point to a missing or mismatched index rather than a logic error.

Should I just create every index SQL Server recommends?

No. Missing-index recommendations are generated from individual queries in isolation and ignore your write workload and existing indexes. Acting on all of them creates redundant indexes that slow down inserts, updates, and deletes. Treat the recommendations as candidates and design a focused set of indexes based on your actual access patterns.

How often should we review database performance?

Schedule reviews on a recurring cadence and after any significant change in data volume, feature scope, or reporting requirements. Indexes that were adequate at launch can degrade as tables grow, so a periodic check of slow queries and execution plans catches problems before users feel them. For most mid-market systems, a quarterly review plus checks after major releases is a reasonable baseline.

Sources

Execution Plans, Microsoft Learn, 2026.
SQL Server Index Design Guide, Microsoft Learn, 2026.
Create Indexes with Included Columns, Microsoft Learn, 2026.

How MCP’s Ensure your AI projects Succeed

Posted on June 8, 2026June 30, 2026 by Artemy

Every week, another business announces an AI initiative. A pilot gets funded, a tool gets selected, and six months later, nothing has changed. No press release declaring success. Just a quiet budget reallocation and a team that has moved on to something else.

This pattern is predictable. And once you understand the structural cause, it becomes preventable.

Most enterprise AI projects do not fail because of the AI. They fail because the AI cannot reach the data it needs to be useful. Model Context Protocol (MCP) is the open standard that closes that gap by giving AI agents a secure, governed way to connect to business systems.

The Real Reason AI Pilots Stall

When organizations evaluate AI, the conversation almost always centers on model capabilities. How accurate is it? How fast does it respond? Can it handle our industry’s terminology?

Those are secondary questions. The primary question is: what can this AI actually see?

Most enterprise AI tools deploy into a vacuum. They can answer general questions, summarize content you paste into them, and generate responses from scratch. What they cannot do, without deliberate integration work, is reach your CRM, check your ticketing queue, read policies from SharePoint, or pull records from your ERP.

The result is an expensive tool that forces users to manually copy-paste context into a chat window. That is not AI-powered business. That is a smarter clipboard.

Employees quickly notice the gap. The AI is only as useful as what they remember to feed it, so they fall back to existing workflows. The pilot generates a handful of interesting demos, produces a slide deck for leadership, and gets quietly deprioritized.

The integration gap is not a technology problem you solve after the pilot. It is a scoping problem you address before the first tool gets selected. AI initiatives that skip integration planning almost always end up rebuilding from scratch.

What Enterprise Systems Are Actually Working With

Most mid-market businesses in Ontario have built their operations across a stack of platforms that were never designed to interoperate cleanly. A typical setup includes some combination of:

CRM: Salesforce, HubSpot, or Microsoft Dynamics
ERP: SAP, NetSuite, or Microsoft Business Central
Document management: SharePoint or Google Drive
Data warehouse: Snowflake, Azure Synapse, or AWS Redshift
Email and calendar: Microsoft 365 or Google Workspace
Ticketing and service desk: ServiceNow, Jira, or Zendesk

Each system holds a critical piece of the business. None of them were designed to feed an AI model. And without a standardized integration layer, connecting an AI agent to each one means building a custom connector, handling authentication separately, writing bespoke translation logic, and then maintaining all of it when systems change.

That work is expensive, slow, and fragile. Most organizations either skip it entirely (and get limited AI value) or build it piecemeal (and end up with technical debt they cannot maintain).

What Is MCP?

Model Context Protocol (MCP) is an open standard developed by Anthropic that defines how AI models and agents securely connect to external data sources and tools. MCP establishes a common interface between AI applications (clients) and business systems (servers), so any MCP-compatible AI can access any MCP-compatible system through a consistent, governed connection. Released in November 2024, MCP is not a proprietary product. It is a vendor-neutral specification designed to become the universal connector layer for enterprise AI.

The analogy that makes it concrete: before MCP, every AI integration was a custom job. Build a unique API bridge, manage credentials per system, write one-off parsing logic. It was the equivalent of wiring a new plug for every outlet in your building.

MCP standardizes the plug. One specification. One authentication model. One governance layer. Vendors build MCP-compatible interfaces for their products once. Any AI agent that supports the protocol can then connect to any compliant system without custom work.

In practice, an MCP server sits between the AI and the enterprise system. When an AI agent needs information, it calls the relevant MCP server. The server authenticates, retrieves the data, and returns it in a standardized format the model can use. The underlying system does not need to change.

MCP vs. Traditional AI Integration: What Changes

The gap between the old approach and MCP is significant across every dimension that matters to enterprise IT.

Dimension	Traditional Integration	With MCP
Integration approach	Custom connector per system, built from scratch	Standardized protocol; reuse across systems and AI tools
Access control	Per-system, inconsistent policies	Centralized; policy-driven at the protocol layer
Time to integrate	Weeks to months per connection	Days to weeks with available MCP servers
Vendor portability	Locked to one AI platform	Portable across any MCP-compatible AI
Audit trail	Fragmented across individual systems	Unified logging at the connection layer
Maintenance burden	High (custom code breaks on system updates)	Lower; vendor maintains the MCP server

Why Governance Is the Deciding Factor

For IT and security teams, the integration problem is fundamentally a governance problem. Custom API integrations are hard to audit, hard to update, and hard to revoke. When an employee changes roles or leaves, tracking down every access point they used is a manual, error-prone exercise. When a third-party vendor gets compromised, knowing exactly which systems were exposed requires digging through configuration files that were never documented centrally.

MCP changes the governance model because access is managed at the protocol layer. You define which agents can connect to which systems. You specify what operations they are permitted to perform and what data they are allowed to retrieve. That access is logged centrally. It can be revoked with a single policy change. It follows your existing security policies rather than creating parallel, informal access channels.

For organizations operating under PIPEDA, PHIPA, or SOC 2 requirements, this is the piece that makes enterprise AI viable rather than aspirational. Security and compliance teams need to be able to answer: who accessed what, when, and why. MCP makes that question answerable across every AI-to-system interaction.

When evaluating AI tools for enterprise use, ask vendors to document their integration architecture specifically. If the answer is “we handle that for you” without a clear explanation of where authentication happens, who controls access, and how connections are audited, that is a vendor lock-in and governance risk to flag before signing anything.

The Vendor Lock-In Problem MCP Solves

There is a second structural issue with enterprise AI adoption that MCP addresses directly: proprietary integration lock-in.

Most AI platforms want to own the integration layer. They build proprietary connectors, store data in their own pipelines, and make migration costly. If you build your AI capabilities on top of one vendor’s ecosystem and that vendor raises prices, changes terms, or gets acquired, you are effectively trapped.

MCP is an open standard maintained by a neutral specification body. That means the integration work you invest in today is portable. The MCP servers you build or license can work with a different AI model, a different platform, or a next-generation tool that does not exist yet. You are building infrastructure, not dependency.

Major technology companies have already signalled adoption. Block, Replit, Sourcegraph, and others began building MCP-compatible tooling within months of the specification’s release. The direction of travel is toward an ecosystem where MCP compatibility is a baseline expectation, not a differentiator.

What to Ask Before Your Next AI Initiative

If your organization has evaluated AI and found the results underwhelming, the integration gap is the most likely culprit. The tools were capable. They just could not see your business.

Before starting your next AI initiative, these are the questions that determine whether it delivers or stalls:

Define the data sources first: Which systems hold the data this AI will need to be useful? List them explicitly before evaluating any tools. If you cannot answer this question, the pilot scope is not defined.

Audit the integration architecture: Ask every vendor how their tool connects to your existing systems. Does it support MCP or another open standard? What does the authentication model look like? Where is access controlled and logged?

Assign ownership of the integration layer: Someone on your team needs to own the connection between AI and business systems. If that responsibility is undefined, integrations will be inconsistent, ungoverned, and unsupported.

Test governance before scale: Before expanding an AI initiative across teams or use cases, verify that access controls, audit logs, and revocation procedures are working as intended. Scaling ungoverned AI access multiplies risk, not just value.

AI does not fail because the technology is immature. It fails because the technology cannot reach the information it needs to do useful work. MCP addresses that at the infrastructure level: standardized connections, centralized governance, and portability across vendors. Getting the integration layer right is what separates an AI pilot from an AI capability.

At Balanced+, we help mid-market businesses in Toronto and the GTA build the IT infrastructure that makes AI adoption practical and secure. If your organization is working through an AI strategy or evaluating where to start, the integration architecture should be the first conversation. Learn more about our AI and machine learning services or book a consultation to talk through your specific environment.

Frequently Asked Questions

Why do most enterprise AI projects fail?

Most enterprise AI projects fail because the AI tool cannot access the business data it needs to be useful. Organizations deploy AI without solving the integration problem first, leaving the tool isolated from CRM records, ERP data, ticketing systems, and document repositories. Without access to live business context, AI adds limited practical value and adoption drops off.

What is Model Context Protocol (MCP)?

Model Context Protocol (MCP) is an open standard released by Anthropic in November 2024 that defines how AI models securely connect to external systems and data sources. It works like a universal adapter: AI agents connect to MCP servers, which handle authentication and data retrieval from enterprise systems like CRMs, ERPs, and ticketing platforms. Because MCP is vendor-neutral, integrations built on it are portable across AI providers.

How does MCP improve AI security and governance?

MCP centralizes access control at the protocol layer rather than managing permissions separately in each connected system. IT teams can define which AI agents are permitted to access which data, log every request, and revoke access centrally if needed. This makes it possible to audit AI behavior across all connected systems from a single control point, which is critical for organizations operating under PIPEDA, PHIPA, or SOC 2 requirements.

Does MCP prevent vendor lock-in?

Yes. Because MCP is an open, vendor-neutral specification, integration work built on the protocol is not tied to a single AI platform. Organizations can switch AI models or vendors without rebuilding their entire integration layer. This is a significant advantage over proprietary connector ecosystems, where migrating away from one vendor’s AI platform often means losing all the integration investment made on top of it.

Sources

Microsoft 365 Business Premium vs. Basic: What SMBs Need

Posted on June 2, 2026June 30, 2026 by Artemy

You are pricing out Microsoft 365 for your team and the spreadsheet math is doing what it always does: Business Basic looks like the obvious win. It is roughly a third of the price of Business Premium, everyone gets email and Teams, and the apps run in the browser. Why pay more? Then someone on your team clicks a credential-harvesting link, the attacker logs in from an unmanaged laptop, and you discover the security controls you skipped were the actual product you were buying.

This post breaks down what genuinely separates Microsoft 365 Business Basic from Business Premium, what each plan costs in Canada, and how to decide which one your business actually needs without overpaying or underprotecting.

The price gap between Business Basic and Business Premium is not really about email or Office apps. It is about security and device management. Premium bundles enterprise-grade tools (Defender for Business, Entra ID P1, Intune, and data-loss prevention) that you would otherwise buy separately or live without. For most Canadian SMBs that handle client data, Premium is the floor, not the upgrade.

Microsoft 365 Business Premium is the top small-business tier of Microsoft 365. It includes everything in Business Standard (desktop and web Office apps, Exchange email, Teams, SharePoint, OneDrive) plus a bundled security and device-management stack: Microsoft Defender for Business, Microsoft Defender for Office 365 Plan 1, Microsoft Entra ID Plan 1, Microsoft Intune, and Azure Information Protection. It is capped at 300 users.

What is the actual difference between Business Basic and Business Premium?

The difference comes down to two things Basic does not include: desktop Office apps and a full security and management layer. Basic gives you the web and mobile versions of Word, Excel, and Outlook, hosted email, and Teams. Premium gives you the installed desktop apps plus the security tooling that protects identities, devices, and data. Business Standard sits in the middle: it adds desktop apps to Basic but stops short of the security stack.

Capability	Business Basic	Business Standard	Business Premium
Web & mobile Office apps	Yes	Yes	Yes
Desktop Office apps (Word, Excel, Outlook)	No	Yes	Yes
Exchange email, Teams, SharePoint, 1 TB OneDrive	Yes	Yes	Yes
Defender for Office 365 (Safe Links, Safe Attachments, anti-phishing)	No	No	Yes
Defender for Business (endpoint detection & response)	No	No	Yes
Entra ID P1 (Conditional Access, self-service password reset)	No	No	Yes
Intune device management (MDM/MAM)	No	No	Yes
Data-loss prevention & information protection	No	No	Yes
Approx. price (CAD, annual, per user/month)	~$8	~$17	~$30

Pricing changes periodically and varies by commitment term, so confirm current figures on Microsoft’s Canadian plan comparison page before you budget. The ratios, however, stay roughly the same: Premium runs about three to four times the cost of Basic.

What does Business Basic actually give you (and what it leaves out)?

Business Basic is a complete cloud productivity suite for a team that lives in the browser. You get hosted Exchange email with a 50 GB mailbox, the web and mobile versions of the core Office apps, Microsoft Teams, SharePoint, and 1 TB of OneDrive storage per user. For a startup of five people running lean, or for frontline staff who only need email and a calendar, it is genuinely enough.

What it leaves out is the part that matters once you have employees, devices, and client data to protect. Basic has no endpoint protection, no managed device enrollment, no Conditional Access to enforce where and how people sign in, and no advanced email filtering beyond the standard built-in spam protection. According to Microsoft’s own Business Premium documentation, those security capabilities are precisely what define the Premium tier. With Basic, you are responsible for sourcing and funding all of it elsewhere.

A common misconception: people assume Basic is “Office without the desktop apps.” That is half true. The desktop apps are the smaller of the two gaps. The bigger gap is that Basic and Standard ship with no managed security layer at all, while Premium does.

What are you really paying for with Business Premium?

You are paying for a bundled enterprise security stack that would cost significantly more to assemble from standalone products. Business Premium folds five distinct tools into the per-user price, and each one closes a specific attack path that Basic leaves open.

Microsoft Entra ID P1 enables Conditional Access, the policy engine that blocks logins from risky locations or unmanaged devices and enforces MFA based on context rather than a blanket rule.
Microsoft Defender for Business adds endpoint detection and response (EDR) across Windows, Mac, iOS, and Android, the kind of behavioural threat detection that catches ransomware before it spreads.
Defender for Office 365 Plan 1 layers Safe Links, Safe Attachments, and advanced anti-phishing onto email, the channel attackers use most.
Microsoft Intune lets you enroll, configure, and remotely wipe company and personal devices, so a lost laptop is an inconvenience rather than a breach.
Azure Information Protection and DLP classify and protect sensitive documents, which matters for PIPEDA, PHIPA, and client-confidentiality obligations.

From a security operations standpoint, the value of Premium is not any single feature. It is that identity, email, endpoint, and data protection are integrated under one policy plane. When we onboard GTA mid-market clients, consolidating these controls into Business Premium often replaces a patchwork of point products that cost more in aggregate and never talked to each other.

Why “saving money” with Basic often costs more

Choosing Basic to save roughly $22 CAD per user each month is a real saving only if you never need the controls it omits. The moment you do (whether to satisfy a cyber-insurance application, pass a client security questionnaire, or simply recover from an incident) the gap shows up as a larger, unbudgeted cost.

Cyber-insurance underwriters increasingly require MFA, endpoint detection and response, and managed device controls before they will issue or renew a policy. On Business Basic you do not have native EDR or Conditional Access, which can mean higher premiums, coverage exclusions, or a declined application. The downgrade decision can quietly become an uninsurable-risk decision.

The math also runs the other way. The IBM Cost of a Data Breach Report 2024 put the global average breach cost at USD 4.88 million, and while a small business will not see that figure, even a contained incident routinely runs into tens of thousands of dollars in downtime, remediation, and lost trust. Against that, the Premium premium for a 25-person company is roughly $550 CAD a month. The security stack pays for itself the first time it prevents a single serious incident.

Which Microsoft 365 plan does your business actually need?

Match the plan to your risk and your workforce, not to the lowest line item. Use this decision sequence:

Do you handle client, financial, or health data? If yes, go to Premium. PIPEDA and PHIPA obligations effectively require the data protection, access controls, and audit capabilities that only Premium bundles natively.

Do you carry, or want, cyber insurance? If yes, go to Premium. Underwriters expect MFA, EDR, and managed devices, and Premium delivers all three out of the box.

Do staff need full desktop Office apps? If yes but you have no elevated security need, Business Standard is the honest middle. If no, Basic can cover browser-only users.

Are you browser-only, low-risk, and pre-revenue? Basic is defensible as a starting point, with a documented plan to move to Premium before you scale or take on sensitive data.

You do not have to standardize on one plan. Microsoft 365 lets you mix licences in the same tenant, so put frontline or browser-only staff on Basic and your knowledge workers and anyone handling sensitive data on Premium. Just make sure the Premium security policies (Conditional Access, Intune enrollment) are scoped to cover the accounts and devices that matter most.

Business Basic and Business Premium are not two sizes of the same thing. Basic is a productivity suite; Premium is a productivity suite with an integrated security platform attached. If your business has data worth protecting or insurance to qualify for, the question is not whether you can afford Premium. It is whether you can afford to skip it.

Picking the licence is the easy part. The value of Business Premium only shows up when the security stack is actually configured: Conditional Access policies written, Intune enrollment enforced, Defender tuned, and DLP rules mapped to your compliance obligations. That is where most SMBs leave the protection they paid for sitting switched off. We help GTA mid-market companies choose the right Microsoft 365 mix and stand up the security controls properly. If you want a second opinion on your current setup, our Microsoft 365 management team can walk through it with you.

Frequently asked questions

Is Microsoft 365 Business Premium worth it over Basic?

For any business that handles client data, carries cyber insurance, or runs company-managed devices, yes. Premium bundles endpoint detection, Conditional Access, device management, and advanced email security that Basic omits entirely. If you were going to buy those controls separately, Premium is almost always cheaper than the sum of the parts.

What is the main difference between Business Basic and Business Premium?

Two things: desktop apps and security. Basic gives you web and mobile Office apps with no security stack. Premium adds the installed desktop apps plus Microsoft Defender for Business, Defender for Office 365, Entra ID P1, Intune, and data-loss prevention. The security layer is the larger and more important difference.

Can I mix Business Basic and Business Premium licences?

Yes. Within a single Microsoft 365 tenant you can assign different plans to different users. Many businesses put browser-only or frontline staff on Basic and put knowledge workers and anyone handling sensitive data on Premium. Just confirm your security policies are scoped to cover the right accounts and devices.

Does Business Basic include any security features?

Basic includes standard built-in spam and malware filtering for Exchange Online and basic multi-factor authentication, but it does not include endpoint detection and response, Conditional Access, managed device controls, or advanced anti-phishing. Those require Business Premium or add-on licensing.

Sources

Compare Microsoft 365 Business Plans, Microsoft Canada, 2026.
Microsoft 365 Business Premium documentation, Microsoft Learn, 2026.
What is Microsoft Defender for Business?, Microsoft Learn, 2026.
What is Conditional Access in Microsoft Entra ID?, Microsoft Learn, 2026.
2024 Data Breach Investigations Report, Verizon, 2024.
Cost of a Data Breach Report 2024, IBM, 2024.

Microsoft 365 DLP Policy Setup: What IT Teams Get Wrong

Posted on May 22, 2026July 7, 2026 by Artemy

You built the DLP policy. The compliance checkbox is checked. Three months later, sensitive data walks out the door anyway. This is not a hypothetical: it is the most common outcome for Microsoft 365 DLP deployments that were done right on paper but wrong in practice.

This post covers the five mistakes that consistently undermine Microsoft Purview DLP deployments in mid-market organizations, what the enforcement limits actually look like, and what a properly structured DLP policy set should include.

Microsoft Purview DLP is not one system; it is four separate enforcement engines that do not share policy scope. Most IT teams configure one engine and assume they are covered. The result is a policy that looks complete in the portal and does nothing for Teams chats, endpoint devices, or SharePoint files uploaded in bulk.

DLP Policy (Microsoft Purview)

A DLP policy in Microsoft Purview is a rule set that detects and acts on sensitive information across Microsoft 365 services. Each policy defines which services to monitor (Exchange, SharePoint, OneDrive, Teams, or endpoint devices), which sensitive information types to detect, and what action to take when a match occurs: audit, warn, block, or notify. Policies are configured in the Microsoft Purview compliance portal and enforced separately by each service’s native engine.

Mistake 1: Treating Microsoft Purview DLP as a Single System

The most damaging architectural misunderstanding in DLP deployments is treating “Microsoft Purview DLP” as a unified enforcement layer. It is not. When you create a policy in the Purview compliance portal, you are writing instructions that will be interpreted separately by up to four different enforcement engines: Exchange Online, SharePoint and OneDrive, Microsoft Teams, and Windows endpoint devices.

Each engine has its own enforcement model, its own latency, and its own limitations. A policy scoped to Exchange will not protect Teams messages, even if the content is identical. A policy covering SharePoint document libraries will not catch a file being copied to a USB drive. These are not bugs; they are the architecture. The problem is that the Purview portal makes it easy to scope a policy to “all locations” with a single toggle, but what that actually enforces in each context requires reading the DLP policy reference documentation carefully.

Warning:

Selecting “All locations” when creating a DLP policy does not mean all enforcement engines are active. Endpoint DLP requires devices to be onboarded to Microsoft Purview separately. If your Windows endpoints are not onboarded, endpoint rules in your policy are silently ignored with no error or alert.

In our work with mid-market GTA organizations, this is the single most common gap we find when reviewing existing DLP configurations: a well-written Exchange policy that was never extended to Teams or SharePoint, because the team assumed one policy covered everything.

Mistake 2: Not Knowing Your Licensing Ceiling Before You Design

Microsoft Purview DLP capabilities are split across licence tiers in ways that are not obvious until you try to enable a feature. Teams message DLP, endpoint DLP, and Adaptive Protection (which dynamically tightens controls based on insider risk signals) all require licences beyond what most mid-market organizations already have.

Feature	M365 Business Premium	M365 E3	M365 E5 / E5 Compliance
Exchange DLP	Yes	Yes	Yes
SharePoint / OneDrive DLP	Yes	Yes	Yes
Teams message DLP	No	No	Yes
Endpoint DLP (Windows)	No	No	Yes
Endpoint DLP (macOS)	No	No	Yes (limited activities)
Adaptive Protection	No	No	Yes
Exact Data Match (EDM)	No	No	Yes

If your organization is on M365 Business Premium or E3, Teams DLP and endpoint DLP are not available without adding the Microsoft 365 E5 Compliance add-on. Knowing this before you build your DLP program means you can scope policies realistically, communicate gaps to leadership, and budget for the correct licence tier if Teams or endpoint coverage is required.

Good to know:

The M365 E5 Compliance add-on can be purchased on top of Business Premium or E3 for specific users who need endpoint or Teams DLP coverage, rather than upgrading your entire tenant. For mid-market organizations with 50 to 200 seats, this is often the most cost-effective path to full coverage.

Mistake 3: Ignoring Policy Priority Order and Conflict Resolution

When multiple DLP policies match the same event, Microsoft Purview applies the most restrictive action from the highest-priority policy. Priority is determined by the order policies appear in the Purview compliance portal: lower number equals higher priority. Most organizations never configure this deliberately. The result is that whichever policy was created first gets the highest priority by default, which is almost never the right outcome.

The practical consequence: if you have a broad informational policy set to audit-only that was created early in your deployment, and a stricter block policy created later, the audit policy will win for any content matching both. Your block rule never fires. This is not visible in normal portal views; you need to check Activity Explorer to see which policy matched and what action was taken.

Use a naming convention that reflects intent and scope from the start: for example, “01-PCI-Block-Exchange,” “02-SIN-Warn-SharePoint,” “03-Confidential-Audit-All.” The numbered prefix makes priority order visible in the portal list without clicking into each policy. Document the intended priority order in a DLP runbook and review it whenever a new policy is added.

Mistake 4: Treating False Positive Management as a Launch Task

Every Purview DLP deployment generates false positives. The volume depends on how broadly your sensitive information types are scoped and how much your organization’s legitimate work involves content that resembles sensitive data. Financial services, legal, and healthcare firms are especially prone to high false positive rates because credit card numbers, Social Insurance Numbers, and health identifiers appear regularly in day-to-day documents.

The mistake is treating false positive resolution as something you do at launch and then move on from. In practice, the alert queue grows continuously. Without a defined review workflow, it becomes a backlog that no one looks at. When the alert queue is ignored, legitimate violations get buried alongside noise, which defeats the purpose of the system entirely.

A workable false positive workflow has three components: a defined owner for the DLP alert queue (usually the IT security lead or a shared security operations function), a weekly triage cadence during the first 90 days of any new policy, and a documented threshold for when a false positive rate triggers a policy tune-up. The DLP Alerts dashboard allows you to classify each alert as a true positive, false positive, or benign — use that classification consistently so you can track your false positive rate over time and demonstrate to leadership that the policy is being actively managed.

Mistake 5: Assuming SharePoint DLP Coverage Is Real-Time

DLP enforcement on SharePoint and OneDrive operates on the search crawler index, not on the file upload event itself. When a file lands in SharePoint, it is not immediately scanned for sensitive content. It is evaluated when the search crawler processes it, which can take anywhere from minutes to several hours depending on crawl queue depth and file volume.

This matters most during bulk data migrations or large file imports. If your organization migrates a file share to SharePoint, thousands of files enter the environment before DLP has had a chance to evaluate any of them. For organizations subject to PIPEDA breach notification obligations, this is a real compliance exposure window, not a theoretical one.

Warning:

If you are planning a SharePoint migration, notify your DLP policy owner before the migration begins. Consider restricting broad access permissions on the destination library during the crawl period and applying sensitivity labels to known-sensitive files before migration to add a secondary control layer while DLP catches up.

What Microsoft Purview DLP Cannot Protect Against

Understanding where enforcement ends is as important as knowing what it covers. These are the gaps no Purview DLP policy can close on its own:

Images and screenshots: Purview DLP does not inspect image files or screen captures for sensitive content. A Social Insurance Number or credit card number in a scanned PDF or screenshot is invisible to the policy engine.
ZIP and compressed archives: Files inside a ZIP archive are not inspected. Sensitive content inside a compressed file bypasses detection entirely.
BYOD and unmanaged personal devices: Endpoint DLP requires Intune management or Purview device onboarding. Personal devices used for work are not covered unless enrolled in device management.
Third-party SaaS applications: Purview DLP does not extend to Slack, Google Drive, Salesforce, or any non-Microsoft SaaS tool. Data moving to or from those platforms is outside scope.
Camera and verbal disclosure: Someone photographing a screen or reading sensitive data aloud cannot be detected by any DLP system. These insider risk scenarios require procedural controls, not technical ones.

These gaps are not reasons to avoid Purview DLP; they are reasons to layer it with complementary controls including managed detection and response, Purview Insider Risk Management, and Conditional Access policies that restrict where sensitive data can be accessed from.

A Minimum Viable DLP Policy Set for Mid-Market Canadian Organizations

Based on deployments across GTA mid-market clients, this is the minimum policy set that provides meaningful coverage across M365 for organizations on E3 or Business Premium. Organizations on E5 should extend each policy to include endpoint and Teams locations where applicable.

Policy 1: Payment Card Data (PCI): Detect credit card numbers across Exchange, SharePoint, and OneDrive. Action: block external sharing, notify sender and compliance team. Run in audit mode for two weeks before enforcing to assess false positive volume.

Policy 2: Social Insurance Numbers (PII): Detect Canadian Social Insurance Numbers across Exchange, SharePoint, and OneDrive. Action: warn on external send, block bulk sharing above five instances. Include a policy tip that explains acceptable handling procedures.

Policy 3: Health Information (PHIPA): For organizations in or serving healthcare, detect health information types across Exchange and SharePoint. Action: block external sharing, alert the privacy officer. Coordinate with your PHIPA compliance lead before going live.

Policy 4: Confidential Label Enforcement: Block or warn on external sharing of any document carrying a “Confidential” or “Highly Confidential” sensitivity label. This requires Microsoft Purview Information Protection labels to be deployed and adopted first. Without label adoption by users, this policy does nothing.

Policy 5: Endpoint DLP (E5 or Compliance Add-On Required): Restrict copy-to-USB, print-to-unmanaged-printer, and browser upload of files containing sensitive information types from Purview-onboarded Windows devices. Deploy in audit mode first; endpoint DLP generates high false positive volume on initial deployment, especially in environments with legacy document workflows.

48%

Of all data breaches involved ransomware or extortion in 2025, according to the Verizon 2026 Data Breach Investigations Report. Uncontrolled data access and exfiltration paths are a primary enabler — which is exactly what a properly configured DLP program is designed to close.

Run each new policy in audit mode for a minimum of two weeks before enforcing it. Use the Activity Explorer in the Purview compliance portal to review which rules are matching, which users are triggering alerts most often, and whether the match is legitimate or a false positive. A policy that generates hundreds of false positive alerts per week will create alert fatigue and lose stakeholder trust before it ever blocks a real violation.

Microsoft Purview DLP is a powerful control, but it requires deliberate architecture decisions. Know which engines you are actually configuring. Know your licensing ceiling before you design. Set policy priority intentionally. Build a false positive workflow before you go live. Document the enforcement gaps so the business understands what DLP does and does not cover. A policy that looks complete in the portal but was never tested end-to-end provides false confidence, and false confidence in a security control is worse than no control at all.

If you are reviewing your M365 DLP configuration or starting from scratch, the team at Balanced+ works with mid-market GTA organizations on managed cybersecurity services that include Purview DLP design, deployment, and ongoing alert management. A configuration review is often enough to surface the most critical gaps before they become incidents.

Frequently Asked Questions

What is a DLP policy in Microsoft 365?

A DLP policy in Microsoft 365 is a rule set configured in the Microsoft Purview compliance portal that detects sensitive information (such as credit card numbers, Social Insurance Numbers, or health data) across M365 services and takes automated action when a match is found. Actions can include auditing the event, displaying a policy tip to the user, blocking the action, or alerting a compliance administrator. Each policy applies separately to the enforcement engine of each selected service location.

Does one DLP policy cover Exchange, Teams, and SharePoint at the same time?

A policy can be scoped to multiple locations, but each location is enforced by a separate engine with its own behaviour and limitations. Teams DLP requires an E5 or E5 Compliance licence; without it, Teams is not covered even if selected in the policy scope. SharePoint enforcement is based on the search crawler index rather than real-time file events. Exchange enforcement is near-real-time. Each location should be verified independently to confirm enforcement is actually active.

How long does it take for a new DLP policy to take effect?

According to Microsoft’s DLP documentation, policies generally take effect about an hour after being turned on. SharePoint and OneDrive enforcement depends on the search crawler, which may add additional lag. Do not test enforcement immediately after creating a policy; allow at least an hour before concluding that a rule is not working.

What is the difference between audit mode and enforce mode in Purview DLP?

In audit mode, Purview DLP logs all policy matches and generates alerts but does not take any action on the content or notify users. This is the recommended starting point for any new policy, as it lets you assess match volume, identify false positives, and tune rules before any user-facing disruption occurs. Enforce mode takes the configured action (such as blocking a send or displaying a policy tip). Moving from audit to enforce should happen only after at least two weeks of alert review and active tuning.

Sources

How AI Agents Automate Business Operations

Posted on March 20, 2026June 30, 2026 by Artemy

Your operations team spent 12 hours last week copying data between spreadsheets. Your IT staff manually checked 40 web pages for uptime. Someone on your marketing team filled out the same test form six times to verify it worked after a plugin update. None of this required human judgment. It just required a human’s time.

That’s changing. AI agents (not chatbots, not basic automations) are now capable of navigating websites, filling out forms, extracting data, and completing multi-step workflows without human intervention. And for mid-market businesses running lean teams, this isn’t a future trend. It’s a competitive advantage available right now.

AI agents aren’t chatbots that answer questions. They’re autonomous tools that take action. They navigate websites, interact with applications, extract data, and complete multi-step business workflows. The difference between a chatbot and an AI agent is the difference between someone who gives you directions and someone who drives you there.

What Are AI Agents (And Why Should You Care Now?)

The term “AI” gets thrown around loosely, so let’s be specific about what we mean when we talk about AI agents in a business context.

AI Agent

A software system powered by a large language model (LLM) that can autonomously plan and execute multi-step tasks. Unlike a chatbot, which only responds to prompts, an AI agent can browse websites, interact with applications, make decisions based on what it finds, and complete workflows from start to finish without human input at each step.

The key word is autonomously. A chatbot waits for your question. An AI agent takes your goal (“check our website for broken links every morning” or “fill out this vendor application form with our company details”) and figures out how to accomplish it.

What makes this possible today is a new category of capability that lets AI agents interact with the real world:

Model Context Protocol (MCP)

An open standard developed by Anthropic that lets AI agents connect to external tools and data sources through a universal interface. MCP servers act as bridges between the AI and real-world systems like web browsers, databases, APIs, file systems, and business applications. Think of MCP as a USB port for AI: instead of building a custom integration for every tool, any MCP-compatible agent can plug into any MCP server and immediately gain new capabilities.

This is the architecture that makes AI agents practical for business. Rather than needing a developer to build custom integrations for every workflow, your team can connect pre-built MCP servers that handle web browsing, database queries, file management, and more. The agent handles the reasoning. The MCP servers handle the doing.

The Tools Behind It: Playwright and Claude Code

Every screenshot in this article was captured by an AI agent browsing a live website in real time. The tool that makes this possible is Playwright, an open-source browser automation framework built by Microsoft. Playwright can control Chromium, Firefox, and WebKit browsers programmatically, navigating pages, clicking buttons, filling forms, and taking screenshots just like a human user would.

What makes Playwright especially powerful for AI agents is the Playwright MCP server. This server wraps Playwright’s capabilities into the Model Context Protocol, so any MCP-compatible AI agent (like Anthropic’s Claude) can control a web browser through natural language instructions. The agent says “navigate to this URL and fill out the contact form,” and the Playwright MCP server translates that into real browser actions.

If you’re using Claude Code (Anthropic’s command-line AI development tool), you can add the Playwright MCP server in under a minute:

That single command gives Claude the ability to open a browser, navigate to any URL, read page content, interact with elements, fill out forms, and capture screenshots. No additional configuration required. Once installed, you can ask Claude to do things like “go to our website and check if the contact form works” and it will open a real browser, run through the workflow, and report back with screenshots of what it found.

This is the same setup we used to generate every demonstration in this article. The form-filling screenshots, the site monitoring captures, the page analysis examples: all produced by Claude controlling a Playwright browser through MCP, running against a live production website.

Playwright MCP is just one of hundreds of available MCP servers. Others connect AI agents to Google Drive, Slack, databases, GitHub, CRM platforms, and more. The MCP ecosystem is growing fast, and each new server expands what your AI agent can do without any custom development.

5 Ways AI Agents Save Your Team Time Every Week

Here’s where this gets practical. These aren’t hypothetical use cases. They’re workflows that businesses are automating with AI agents today.

1. Automated Website Monitoring

An AI agent can navigate your entire website on a schedule, checking that pages load correctly, forms function, SSL certificates are valid, and content hasn’t been tampered with. Unlike basic uptime monitors that only check if a server responds, an AI agent actually sees the page the way a visitor would.

Screenshot of an AI agent automatically monitoring the BALANCED+ homepage for uptime and content changes — An AI agent navigating to a business website to verify the homepage loads correctly, checking navigation elements, hero content, and page structure, all without human intervention.

If something is wrong (a broken image, a missing phone number, a form that throws an error) the agent flags it immediately. No more finding out about broken pages from a customer complaint.

2. Competitive Intelligence on Autopilot

Want to know when a competitor updates their pricing page, launches a new service, or publishes a blog post targeting your keywords? An AI agent can monitor competitor websites daily, extract the relevant changes, and deliver a summary to your inbox every morning.

Screenshot of an AI agent automatically scanning a company blog page to gather competitive intelligence and content insights — An AI agent scanning a blog index page. It can read headlines, categorize content topics, and track publishing frequency across multiple competitor sites automatically.

This used to require a junior analyst spending hours clicking through competitor sites. Now it runs in the background while your team focuses on acting on the insights instead of gathering them.

3. Automated Form Testing

Every time you update a WordPress plugin, change a form field, or modify your contact page, there’s a risk that something breaks. AI agents can automatically test your forms by navigating to the page, filling in every field with realistic test data, submitting, and verifying the confirmation message appears.

Screenshot showing an AI agent that has automatically filled in all fields of a contact form including name, email, company, service type, and message — A real demonstration: an AI agent navigated to a contact form, identified all input fields, selected the appropriate service category from a dropdown, and composed a realistic message, in seconds.

Run this after every deployment and you’ll catch broken forms before your prospects do. That’s leads you’d otherwise lose without ever knowing it.

15-25 hrs/week

Time mid-market teams typically spend on manual web tasks that AI agents can automate, including monitoring, data collection, form testing, and report generation. (Internal benchmarks across 50+ managed accounts)

4. Data Collection and Reporting

Need to pull pricing data from vendor portals every week? Aggregate job postings across multiple boards? Collect product specifications from supplier websites? AI agents handle repetitive data collection tasks that would otherwise eat hours of your team’s week.

The agent navigates to each source, extracts the data you’ve specified, normalizes it into a consistent format, and delivers it to a spreadsheet, database, or dashboard. When a source changes its layout (something that would break a traditional scraper) the AI agent adapts because it understands the page structure, not just the HTML.

5. Employee Onboarding Workflows

Onboarding a new employee involves creating accounts across multiple platforms: email, project management, HR systems, security training, VPN access. An AI agent can work through an onboarding checklist, navigating to each platform, creating accounts with the correct permissions, and logging what was completed.

This reduces onboarding from a half-day IT task to a supervised 30-minute process, with a complete audit trail of exactly what was provisioned and when.

Start with one workflow. Pick the most repetitive, lowest-risk task your team does every week (website monitoring or form testing are great candidates) and automate that first. Once you see the time savings and reliability improvements, you’ll quickly identify the next five workflows to hand off to an AI agent.

What This Looks Like in Practice

To make this concrete, here’s exactly what happens when an AI agent automates a form testing workflow, one of the most common use cases we see with our managed IT clients.

Step 1: The agent receives its instructions. You define the task once: “Navigate to our contact page, fill out the form with test data, submit it, and verify the confirmation message appears. Run this every morning at 7 AM and alert me if anything fails.” The agent stores these instructions and executes them on schedule.

Step 2: The agent navigates to the page. Using the Playwright MCP server, the agent opens a real Chromium browser, navigates to your contact page, and waits for it to fully load, just like a real visitor would.

Step 3: The agent reads the page and identifies the form. Rather than relying on hardcoded selectors that break when your page changes, the AI agent understands the page structure. It identifies the form fields by their labels (First Name, Last Name, Email, Message) and knows what type of data each expects.

Step 4: The agent fills and submits the form. Each field gets populated with realistic test data. Dropdowns are selected, text areas are filled with appropriate content, and the submit button is clicked. The agent then waits for the page response.

Step 5: The agent verifies the result and reports back. Did a confirmation message appear? Did the page throw an error? Did the form redirect to a thank-you page? The agent checks for the expected outcome and sends a pass/fail report. If something broke, you know about it before your first prospect of the day hits that form.

Here’s what the agent actually sees at each stage. These are real screenshots captured by an AI agent during a live demonstration:

Screenshot of an AI agent navigating to the BALANCED+ contact page to begin automated form testing — Step 2 in action: the AI agent has navigated to the contact page and is ready to identify and interact with the form fields.

Screenshot of an AI agent navigating and analyzing a Managed IT Services webpage for content and structure — The same agent can navigate to any page on the site. Here it’s analyzing a services page, reading the content structure, checking for missing elements, and verifying that all links resolve correctly.

How AI Agents Compare to Traditional Automation

If you’ve used scripts, macros, or tools like Zapier before, you might be wondering what’s different here. The short answer: AI agents handle complexity and change in ways that traditional automation can’t.

	Scripts & Macros	AI Agents
Setup	Requires a developer to write and test custom code	Describe what you want in plain language
Maintenance	Breaks when the target website or application changes its layout	Adapts automatically by understanding page structure, not just HTML selectors
Flexibility	Does exactly one thing; any variation requires new code	Handles variations and edge cases by reasoning about the task
Cost	Low per-script, but developer time for each new automation adds up	Higher per-task compute cost, but dramatically lower setup and maintenance time
Learning curve	Requires programming knowledge (Python, JavaScript, etc.)	Natural language instructions allow your operations team to define workflows
Error handling	Fails silently or crashes when encountering unexpected states	Recognizes errors, attempts recovery, and reports what went wrong in plain language

Traditional automation still has its place. For high-volume, unchanging tasks, a well-written script is faster and cheaper per execution. But for the kind of varied, web-based workflows that mid-market operations teams deal with daily, AI agents are a step change in what’s possible without a dedicated development team.

What to Consider Before You Start

Warning:

AI agents are powerful, but they need guardrails. Before deploying any AI automation in your business, make sure you have these fundamentals in place: Start small and automate one low-risk workflow first, then validate the results before scaling. Define clear boundaries by specifying exactly what the agent should and shouldn’t do, especially around sensitive data and customer-facing interactions. Maintain human oversight because AI agents should report to humans, not replace human judgment on decisions that matter. Ensure security controls so that any tool interacting with your systems has proper access controls, credential management, and audit logging.

The biggest mistake businesses make with AI automation is trying to automate everything at once. The teams that get the most value start with a focused pilot, measure the results, and expand methodically.

You should also consider data privacy. AI agents that browse the web and interact with applications are processing data. Make sure your implementation complies with your organization’s data handling policies and any applicable regulations (PIPEDA in Canada, GDPR for European clients, etc.).

The Bottom Line

AI agents represent a genuine shift in what small and mid-market teams can accomplish without growing headcount. The manual web tasks that eat 15 to 25 hours of your team’s week (monitoring, testing, data collection, reporting) can run autonomously with better accuracy and complete audit trails. The technology is here now, the ROI is measurable, and the barrier to entry is lower than most businesses expect. The question isn’t whether AI agents will change how your team works. It’s whether you’ll be the one setting the pace or playing catch-up.

Ready to explore how AI-powered automation could work for your business? Our team helps mid-market companies identify the right workflows to automate and implement the tools to make it happen, securely and strategically.

Book a consultation to discuss your automation opportunities, or learn more about our managed IT services that keep the foundation running while you innovate.

FortiOS 8.0 Is Here: Everything Announced at Fortinet Accelerate 2026

Posted on March 10, 2026June 30, 2026 by Artemy

The BALANCED+ team is on the ground at Fortinet Accelerate 2026 in Las Vegas this week, and the headline announcement is a big one: FortiOS 8.0 is here. This is the most significant platform update Fortinet has shipped in years, and it changes how organizations should think about network security, AI-driven threat protection, and quantum readiness.

Here’s what matters for mid-market IT leaders and security teams.

FortiOS 8.0: One Platform, Not Twelve Tools

The core message behind FortiOS 8.0 is consolidation. Fortinet has rebuilt the operating system to bridge advanced networking with AI-driven security natively, no bolt-on integrations, no stitching together separate products.

FortiOS 8.0

Fortinet’s natively integrated operating system that unifies networking and security into a single platform. It consolidates endpoint protection, zero-trust access, threat detection, and network management under one OS, replacing fragmented legacy tool stacks.

The consolidation breaks down into three pillars:

One Unified Agent (FortiClient): Integrates endpoint protection (EPP), zero-trust network access (ZTNA), and endpoint detection and response (EDR) into a single agent. It now supports post-quantum cryptography for VPNs, adaptive ZTNA posture visibility, and AI application control.

One Management Tool (FortiManager): Centralized control across campus, branch, and cloud environments. FortiAI-Assist is now built in, using generative AI to simplify network management and reduce human error.

One Data Lake (FortiAnalyzer): Upgraded with a unified XDR dashboard for instant risk assessment across network, endpoint, and identity domains. SOC monitoring moves to machine-speed response.

AI Built Into the Core, Not Layered on Top

Fortinet has embedded what they call “Native AI” directly inline within FortiOS 8.0. This isn’t a chatbot slapped onto a dashboard, it’s machine learning running inside the inspection engine to stop zero-day and AI-powered attacks at wire speed without adding latency.

Good to know:

FortiOS 8.0 introduces three distinct AI engines: FortiAI-SecureAI for securing AI workloads, FortiAI-Protect for inline threat prevention, and FortiAI-Assist for guided configuration and troubleshooting, each purpose-built for a different security function.

The practical impact for security teams:

AI-powered IPS for DNS, catches malicious DNS queries that signature-based systems miss
Application-to-application (A2A) detection, visibility into machine-to-machine API traffic
GenAI usage controls, deep visibility and governance over how employees use tools like ChatGPT, Copilot, and other AI services
FortiAI-Assist for FortiGate, AI-driven tooltips, guided suggestions, and debugging assistance that help close the security skills gap

The GenAI governance capabilities in FortiOS 8.0 are a direct answer to one of the biggest shadow IT risks in 2026. If your organization hasn’t established policies for AI tool usage, this update gives you enforcement at the network level, not just a written policy that nobody follows.

Post-Quantum Cryptography: Preparing for Tomorrow’s Threats Today

This is the part that should get every CISO’s attention. Fortinet is building post-quantum cryptography (PQC) and Quantum Key Distribution (QKD) directly into FortiOS 8.0, not as an add-on license or future roadmap item.

Warning:

The “harvest-now, decrypt-later” threat is real. Adversaries are already capturing encrypted traffic today with the expectation that quantum computers will crack it within the next decade. If your VPN tunnels or data transfers carry sensitive information, the window to act is now, not when quantum computing matures.

What FortiOS 8.0 delivers on the quantum front:

Support for NIST-approved PQC algorithms (FIPS 204 and FIPS 205)
Full SSL/TLS deep inspection with quantum-safe encryption
Quantum-resilient management access and agentless VPNs
Minimal performance impact, critical for production environments

FIPS 204 & 205

NIST-approved post-quantum cryptography standards now supported natively in FortiOS 8.0

Next-Gen Security Operations: FortiSOC Gets Agentic AI

Fortinet’s SOC platform, spanning SIEM, SOAR, and XDR, now leverages what they call “Agentic AI.” These are embedded AI agents within FortiAnalyzer that autonomously handle alert triage, root-cause investigation, and response orchestration.

Agentic AI

AI systems that operate autonomously to complete multi-step tasks without constant human direction. In the context of FortiSOC, agentic AI conducts initial alert triage, investigates root causes, and recommends or executes response actions, reducing the volume of work that requires a human analyst.

For organizations already running SOC operations (in-house or outsourced), this translates to:

Faster mean time to detect (MTTD) and mean time to respond (MTTR)
Reduced analyst fatigue from alert noise
Identity-driven detections that catch credential-based attacks earlier in the kill chain

Unified SASE and the All-in-One Bundle

Fortinet continues to push the convergence of networking and security with some significant packaging and architecture changes:

All-in-One Services Bundle: Consolidates 5 SKUs and premium care into a single SKU. Organizations can extend SD-WAN to full SASE at roughly 40% of the FortiGate model cost, a significant reduction in licensing complexity.

Sovereign SASE: Rolling out in 2025–2026, this gives organizations the flexibility to run SASE with data sovereignty controls, critical for Canadian organizations subject to PIPEDA and provincial privacy regulations.

FortiASIC SP5: Fortinet’s proprietary ASICs now support up to 14 different applications simultaneously, including 5G, VXLAN, OT, and Zero Trust workloads, delivering hardware-accelerated performance where software alone can’t keep up.

40%

Cost reduction when extending SD-WAN to full SASE using the new All-in-One Services Bundle vs. individual FortiGate licensing

Data Loss Prevention Gets Serious Upgrades

Data governance is no longer a nice-to-have. FortiOS 8.0 significantly expands its DLP and content inspection capabilities:

OCR-powered inspection via FortiGuard DLP, catches sensitive data embedded in images and scanned documents
Image classification through URL filtering, blocks visual content that text-based filters miss
FortiData Labels aligned with Microsoft Information Protection (MIP), consistent data classification across apps and environments

The MIP alignment is particularly relevant for organizations running Microsoft 365. If you’ve already invested in Microsoft’s data classification labels, FortiOS 8.0 can now enforce those same labels at the network perimeter, creating a unified governance model from endpoint to firewall.

OT Security Extends to the Industrial Edge

For organizations with operational technology environments, manufacturing floors, utilities, critical infrastructure, FortiOS 8.0 extends advanced security controls directly to the industrial edge:

Virtual IP (VIP) support for encrypted communications to OT servers
Strong segmentation between IT and OT networks
Enhanced IPsec connectivity for remote OT sites
Compliance and audit readiness for NERC CIP and IEC 62443 standards

What This Means for Your Organization

FortiOS 8.0 isn’t an incremental update, it’s a platform shift. The consolidation of endpoint, network, and cloud security under one OS eliminates the integration tax that mid-market businesses have been paying for years. The native AI capabilities move threat detection from human-speed to machine-speed. And the post-quantum readiness gives organizations a concrete path to protect data against future decryption threats.

As an authorized Fortinet partner, the BALANCED+ team is at Accelerate 2026 getting hands-on with FortiOS 8.0 and evaluating how these capabilities translate to real-world deployments for our clients. If you’re running Fortinet infrastructure, or considering it, this is the right time to have a conversation about your upgrade path.

Talk to BALANCED+ about your FortiOS 8.0 upgrade path →

.NET EF Identity Resolution, the Hard Way

Posted on March 5, 2026June 30, 2026 by Artemy

Why do two seemingly identical database queries return different values? That’s the question that kicked off an hours-long debugging session, one that revealed a subtle but dangerous interaction between .NET Entity Framework’s Identity Resolution and improper DbContext management.

Entity Framework Core tracks every entity it loads by primary key. If a helper class creates its own DbContext instead of sharing one through Dependency Injection, the two contexts maintain separate identity caches. Changes made in one are invisible to the other, leading to silent data resets that are incredibly hard to trace.

The Problem

The scenario was straightforward on the surface. An API endpoint increments and saves a “Counter” property on a Parts entity mid-execution. The database reflects the correct value after the save. But by the time the endpoint finishes, the Counter resets to its original value, as if the increment never happened.

The culprit line? A completely unrelated save operation on the same entity, updating different fields. Somehow, saving unrelated properties was overwriting the Counter with a stale value. The Counter wasn’t being touched anywhere else in the code, so where was the old value coming from?

// These two lines return DIFFERENT Counter values
// even though they query the same row at the same time:

var counter1 = dbContext.Parts.Find(partId).Counter;
// Returns: 5 (stale, from identity cache)

var counter2 = dbContext.Parts
    .AsNoTracking()
    .First(p => p.Id == partId).Counter;
// Returns: 6 (correct, fresh from database)

The Debugging Journey

Tracking this down required a methodical approach. Each step peeled back another layer of the problem, and each result added to the confusion before the full picture emerged.

Pinpoint the Reset

By commenting out lines one at a time, the exact statement that resets the Counter was identified: an SaveChanges() call that updates completely unrelated fields on the same entity. The Counter value in the database is correct before this line runs, and wrong after.

Inspect the In-Memory Object

Logging the part instance’s Counter value showed it was already stale, holding the original value, not the incremented one. But the increment and save had already succeeded. Where was this stale copy coming from?

Query a Fresh Copy

Selecting another copy of the same row from the database using a standard LINQ query also returned the wrong Counter value, even though the database showed the correct value at that exact moment. Two queries, same row, both stale.

Bypass the Cache

As a final test, querying the Counter value with AsNoTracking(), which skips EF’s caching layer entirely, returned the correct value. This confirmed the problem wasn’t in the database. It was in EF’s own tracking system.

The Root Cause

The answer comes down to two concepts colliding: Entity Framework’s Identity Resolution and the way the DbContext was being managed in this codebase.

Identity Resolution (EF Core)

When Entity Framework returns an entity from the database, it tracks that instance by its primary key. Any subsequent query for the same entity returns the already-tracked instance from memory rather than hitting the database again. This improves performance and reduces memory usage, but it means in-memory values can drift from what’s actually in the database.

Identity Resolution on its own isn’t enough to cause this bug. The real issue was how the codebase managed its DbContext instances.

Warning:

The API endpoint’s logic was split between a parent controller and a helper class. Instead of receiving the DbContext through Dependency Injection (or even as a constructor argument), the helper class instantiated its own new AppDbContext(). This created two completely separate tracking contexts, each with its own Identity Resolution cache, oblivious to changes made by the other.

Here’s what happened step by step: The parent controller incremented the Counter and saved it through its DbContext, the database now holds the correct value. Then the helper class, using its own separate DbContext, queried the same entity. Its Identity Resolution cache still held the original, pre-increment value. When the helper saved its unrelated changes, it overwrote the Counter with the stale cached value.

separate DbContext instances were active in the same API request, each maintaining its own identity cache, silently fighting over the same data.

The Fix

Always use Dependency Injection for your DbContext. Never instantiate new DbContext() inside helper classes, services, or utility methods. One HTTP request should use one DbContext instance, giving every component the same source of truth and the same Identity Resolution cache.

The fix was simple once the root cause was clear. Instead of the helper class creating its own DbContext, the existing context is passed through the constructor:

// BEFORE: helper creates its own context (broken)
public class PartHelper
{
    private readonly AppDbContext _db = new AppDbContext();
    // This context has NO knowledge of changes
    // made by the parent controller's context
}

// AFTER: context is injected (correct)
public class PartHelper
{
    private readonly AppDbContext _db;
    public PartHelper(AppDbContext db) => _db = db;
    // Now shares the same tracking cache as the parent
}

With a single shared DbContext, both the parent controller and the helper class read from and write to the same Identity Resolution cache. The Counter increment is visible everywhere, and no save operation can silently overwrite it with a stale value.

The Takeaway

Going back to the original mystery, those two “identical” queries that returned different values, the explanation is now clear. The first query (Find()) consults the Identity Resolution cache and returns the tracked instance with its stale Counter value. The second query (AsNoTracking()) bypasses the cache entirely and fetches the real, current value from the database.

This kind of bug is particularly dangerous because it’s silent. No exceptions are thrown. No logs indicate a problem. The data just quietly reverts, and everything looks normal until someone notices the numbers don’t add up.

Tip:

Quick reference: dbContext.Entity.Find(id) returns the tracked, potentially stale instance from the Identity Resolution cache. dbContext.Entity.AsNoTracking().First(...) always fetches fresh data from the database. When debugging unexpected values, AsNoTracking() is your fastest way to check if Identity Resolution is the culprit.

The process to find the solution was far more complex than the solution itself, but that’s often how it goes with framework-level bugs. Understanding Identity Resolution isn’t just useful for debugging; it’s essential knowledge for building reliable .NET applications that don’t silently corrupt their own data.

What Is SAMI? And How Does it Benefit Your Business?

Posted on February 13, 2026June 30, 2026 by Artemy

You’ve invested in a firewall. You’ve got endpoint protection. Maybe you’ve even run a penetration test in the last year or two. On paper, it looks like you’re covered.

But here’s the question most business owners and IT managers don’t ask often enough: how much of your security is based on what already happened versus what’s happening right now?

Most cybersecurity tools are designed to detect and respond. Something triggers an alert, someone investigates, and the team reacts. That model worked when threats moved slowly and attackers followed predictable patterns. That’s not the world we’re operating in anymore. Attacks are faster, more automated, and increasingly targeting the gaps between your tools rather than the tools themselves.

The businesses that are getting ahead of this aren’t necessarily spending more. They’re shifting from a reactive model to a continuous one. That’s where Continuous Threat Exposure Management comes in, and it’s why platforms like SAMI are gaining serious traction.

Why Reactive Cybersecurity Isn’t Enough Anymore

The traditional approach to cybersecurity follows a familiar cycle. You deploy tools, configure them, and wait. When something goes wrong, you respond. Between incidents, you might run a quarterly vulnerability scan or an annual penetration test to check for gaps.

The problem is what happens in between those checkpoints.

Threat actors aren’t waiting for your next scheduled audit. They’re probing your environment continuously, looking for misconfigurations, unpatched systems, exposed credentials, and gaps between your security layers. A vulnerability that didn’t exist on Monday can be actively exploited by Wednesday.

For businesses without a dedicated 24/7 security operations center or a large internal security team, that window between discovery and response is where the real damage happens. Ransomware doesn’t wait for your IT person to get back from lunch. A compromised credential doesn’t pause while your security vendor schedules a review.

The reactive model creates a dangerous illusion. You feel protected because you have tools in place. But those tools are only as effective as the moment they were last validated. And for most businesses, that moment was weeks or months ago.

What Is Continuous Threat Exposure Management (CTEM)?

Continuous Threat Exposure Management is a fundamentally different approach to cybersecurity. Instead of periodic assessments and reactive alerting, CTEM continuously identifies, prioritizes, and remediates security risks based on their actual business impact.

Think of it this way. A traditional security model is like getting a physical once a year. CTEM is like wearing a monitor that tracks your vitals in real time and alerts you the moment something needs attention.

With CTEM, your security posture isn’t a snapshot. It’s a live feed. Vulnerabilities are identified as they emerge. Risks are ranked not just by technical severity but by how much damage they could cause to your specific business. Remediation is guided and prioritized so your team isn’t chasing low-impact alerts while critical exposures sit unaddressed.

This matters especially for organizations navigating compliance requirements like SOC2, ISO 27001, or PIPEDA. Auditors increasingly want to see that security isn’t just a point-in-time exercise but a continuous, demonstrable practice. CTEM gives you that evidence.

It also addresses a frustration many business leaders share: spending money on security without ever feeling confident it’s actually working. CTEM closes that gap by providing measurable, ongoing validation rather than assumptions.

What Is SAMI?

SAMI, which stands for Security Assisted by Machine Intelligence, is Autnhive’s cloud-based, AI-driven CTEM platform. It’s designed to help organizations move from reactive security to continuous, proactive threat management across IT, OT, and AI environments.

At a high level, SAMI continuously scans, tests, and validates your security environment. Rather than relying on a single annual pen test or periodic vulnerability scan, SAMI automates and runs these assessments on an ongoing basis, identifying exposures as they appear and prioritizing them based on real business risk.

Key capabilities include:

Automated penetration testing and attack simulations that run continuously rather than once a year
CIS Benchmarking and endpoint assessments to validate configurations against industry standards
Third-party application and risk assessments covering mobile, desktop, and cloud-native environments
AI security features including firewall protection for AI systems, assessment of large language models (LLMs), and monitoring of agentic workflows
Real-time SOC monitoring with live, firewall-based detection and enforcement

SAMI was developed in Canada and is built to integrate directly into existing security operations and SOC workflows. It’s not a rip-and-replace platform. It layers into what you already have and fills the gaps that periodic tools leave behind.

How SAMI Benefits Your Business

For business owners and IT leaders managing competing priorities with limited resources, the practical benefits of SAMI come down to a few key areas.

Real-time visibility instead of blind spots. Most businesses have gaps between their security tools that they don’t even know about. SAMI provides continuous visibility across your entire environment, so risks don’t sit undetected for weeks or months.

Risk prioritization based on business impact. Not every vulnerability is equal. SAMI ranks exposures based on how much damage they could actually cause to your operations, so your team focuses on what matters most rather than drowning in low-priority alerts.

Compliance and governance support. Whether you’re working toward SOC2, ISO 27001, or navigating PIPEDA requirements, SAMI provides the continuous validation and documentation that auditors and regulators want to see. It also aligns with emerging AI regulations and governance frameworks.

Protection that scales without adding headcount. You don’t need to build an internal SOC or hire a team of security analysts to benefit from CTEM. SAMI automates the testing, monitoring, and prioritization that would otherwise require significant staff investment.

SOC-ready outcomes. SAMI doesn’t just generate reports. It delivers actionable, SOC-integrated results that fit directly into security workflows, reducing the time between identification and remediation.

AI environment protection. As businesses adopt AI tools, LLMs, and automated workflows, SAMI extends security coverage into these environments. This is an area where most traditional security tools have no visibility at all.

Why BALANCED+ Is Bringing SAMI to Canadian Businesses

BALANCED+ has been named a Premier Channel Partner and Value-Added Reseller of the SAMI platform in Canada. This partnership means Canadian businesses get more than just access to the platform. They get the advisory, deployment, and operational expertise to make it work within their existing environment.

BALANCED+ delivers SAMI with hands-on support, helping organizations integrate CTEM into their security operations from day one. That includes deployment planning, configuration, SOC workflow integration, and ongoing operational guidance.

“SAMI delivers exactly what enterprise security leaders are asking for, continuous validation, real-time protection, and SOC-ready outcomes across both infrastructure and AI,” said Kevin Milloy, Director of Sales at BALANCED+. “We’re proud to bring this Canadian-developed platform to customers across Canada.”

For businesses that have been investing in cybersecurity tools but still feel uncertain about their actual level of protection, this partnership is designed to close that gap.

Moving from Reactive to Continuous

The cybersecurity landscape has shifted. Threats are continuous, automated, and increasingly sophisticated. The tools and approaches that worked five years ago were built for a different environment.

Continuous Threat Exposure Management represents the next evolution, not just in technology, but in how businesses think about security. It’s the difference between hoping your defenses hold and knowing, in real time, where you stand.

If you’re evaluating your cybersecurity strategy and wondering whether your current approach gives you the visibility and confidence you need, understanding CTEM is a strong place to start.

Learn More About Continuous Threat Exposure Management Want to explore how CTEM and the SAMI platform could fit into your security strategy? Connect with the BALANCED+ team to learn more about proactive cybersecurity for Canadian businesses.