A composite story about rolling XDR into a 50-seat SME, what it actually caught, and where the value showed up.

The client had been a managed-services customer of ours for about two years when the cyber-insurance renewal landed. A creative agency of just under 50 people across one office in south-east London, mostly Mac-led with a Windows fleet on the finance and ops side. The renewal questionnaire had grown by about a page versus the previous year, and one of the new questions was direct: do you have an XDR or MDR solution deployed across all endpoints?

XDR is extended detection and response, the modern security platform that watches laptops, network and cloud for suspicious behaviour, with the ability to isolate a machine if something looks bad. MDR (managed detection and response) is the same capability run as a service. The client had neither. They had a well-patched Mac and Windows estate with some endpoint anti-virus (the older “scan files for known bad stuff” tool) left over from the previous IT contractor. The insurer wasn’t going to renew on those terms.

What looked like the scope

The brief was time-boxed by the renewal date, ten weeks before the existing policy lapsed. The client needed deployment across all 50 endpoints (the laptops, desktops and a small number of phones the team actually worked on), written evidence for the insurer, and a sustainable operating model. Somebody had to be looking at the alerts.

We scoped a six-week rollout with two weeks of monitoring tuning afterwards. Vendor selection had been narrowed by the client’s preference for a stack that played well with Microsoft 365, and by our preference for a vendor with a usable Mac agent. We ran a two-week pilot with the shortlisted product on a dozen endpoints across design, finance, account management, and leadership. The agent was unobtrusive, the dashboard was readable, the pricing landed inside the renewal-driven budget. We placed the order and started the wider rollout.

What actually showed up

Three things surfaced in the rollout that we hadn’t fully scoped for.

First, the Mac fleet was less standardised than we’d thought. About 80% of the Macs were on the current OS with the agent deploying cleanly. The remaining 20% were on older versions. One designer was still on macOS Monterey because of a plug-in that hadn’t been updated. The agent ran on the older versions, but with reduced telemetry. We landed on a hybrid: most older Macs got upgraded with the user’s consent; three were left on the older OS with the gap documented for the insurer.

Second, the agent surfaced things on day one that the existing AV had no visibility on. These were behavioural signals rather than malware. A finance laptop running an unauthorised remote-access tool the user had installed themselves. A creative director’s machine with a browser extension exfiltrating clipboard data (copying what users had on their clipboard out to a third party in the background) to an unapproved analytics service. Two laptops with cached credentials for systems the users had no business accessing. None were urgent in the “we’re being attacked right now” sense, but every one was a real finding the previous AV had no way of seeing. We triaged them with the client over a week, documented and resolved each item, and none required a full incident response.

Third, the alert volume in the first month was higher than we’d budgeted for. Every XDR deployment generates noise in the first 30-60 days while the baseline of normal gets established. We knew this in the abstract. We hadn’t fully translated it into “you’ll need to spend about six hours a week on alerts for the first month, then it drops off.” The client’s in-house ops person was sandbagged for a fortnight while we tuned the baseline. We absorbed the tuning as part of the project. By week eight the daily volume was sustainable, with us in the loop for anything escalated.

How we handled it

The framing we landed on with the client was: this is two projects, not one. Project one is the rollout: agent on every endpoint, insurer’s evidence in writing, renewal date hit. Project two is the operating model: who’s looking at what, on what cadence, with what escalation path to us.

We delivered both. The rollout closed on week six with documentation signed off. The operating model came together over the following four weeks, settling into a rhythm where the in-house ops person triaged daily alerts, we got a weekly summary, and anything classified high-severity routed to us in real time. The insurer accepted the evidence. Renewal landed at a roughly comparable premium to the previous year, which, given how much that market has hardened, counted as a win.

What changed and what didn’t

What changed: visibility. The client now sees what’s happening on their endpoints in a way they previously didn’t. They’ve caught two phishing-triggered credential events in the months since, both contained within minutes by the agent isolating the machine. Neither would have been caught by the previous AV. The in-house ops person has built a working understanding of what normal looks like and when to raise the flag.

What didn’t change: the work the agency does or, for most of the team, how their laptop feels. The agent is, as advertised, unobtrusive. The one exception was the design team. A few people noticed a brief slowdown during the daily scan in the first fortnight. We moved the scan to a different time of day and the complaints stopped.

What also didn’t change: their need to keep doing the basics. XDR doesn’t replace patching, MFA (multi-factor authentication, a code as well as a password), backups, training, or a sensible password manager. It catches the things that get past those layers. XDR is not a silver bullet, and the client needed to hear that explicitly before signing.

What we’d do differently

Two things stand out in hindsight. First, the operating model should have been scoped from week one, not bolted on at week six. We treated the rollout as the project and the alert-handling as the follow-up. In practice the two are inseparable. A deployed XDR that nobody’s looking at is more dangerous than no XDR, because it gives the impression of cover without delivering it. Next time we’ll scope the operating model alongside the rollout and bring the alert-handling owner into the project from day one.

Second, the OS standardisation pass should have happened before the rollout, not during. Catching the older macOS instances during deployment created some friction we could have removed by running a one-week patch-and-version sweep two weeks before the agent install. We’ve added that step to our XDR rollout template.

Practical lessons

A few things worth carrying into any XDR or MDR rollout in an SME:

  • The insurance question is increasingly direct. “Do you have XDR or MDR” appeared in roughly two-thirds of the SME cyber-insurance renewals we saw in the last 12 months. Plan for it.
  • Mac fleets aren’t as homogeneous as they look. Run an OS audit before the agent install. The older outliers will need a decision.
  • Day-one findings are normal, and useful. Don’t panic. Triage them, document them, fix them. The insurer cares more that you can see them than that they exist.
  • First-month alert volume needs explicit budget. Six hours a week for the first month, dropping to one or two thereafter, is a reasonable rule of thumb.
  • Operating model and deployment are the same project, not consecutive ones. A deployed agent with no human watching it is a worse outcome than a tighter deployment with clear ownership.
  • XDR doesn’t replace the basics. Patching, MFA, backups, training, password manager. The order of operations matters.

Where Security Solutions sits

XDR rollouts are a representative chunk of what Security Solutions does for SMEs. The deployment is the visible part. The operating-model design and the ongoing alert-triage relationship are the parts that make the deployment worth doing. We’ll deliver both, and we’ll co-pilot with an in-house team where one exists.

If you’re working through an XDR or MDR decision and not sure where to start, that’s our Security Solutions practice. Drop us a note at info@jmopartners.co.uk and we’ll walk through the operating-model questions before the procurement questions.

JMO|Partners · Enterprise IT, sized for SMEs.