24/7 threat monitoring and expert response for your business

Microsoft sells the engine; we supply the people and the content that operate it. Concretely: detection correlations written and continuously updated into your own Sentinel, alert tuning specific to your environment, and triage that establishes whether something is a true positive before it reaches you — plus threat intelligence enrichment, proactive hunting for activity that evaded the tooling, and a periodic assessment of how your Defender estate is actually configured. The licences, the ingestion and the raw data stay yours: your logs are aggregated and stored in your own Azure tenant, not ours. What you are buying is the twenty-four-hour operation of a platform you already own.

Neither, exactly — and it is worth being precise, because the industry is not.

The contracted commitment is a single Time to Respond: 15 minutes, the same for every severity from critical to low. It is measured machine to machine — from the system timestamp when an incident is created in the platform to the system timestamp when initial triage and classification complete — and the measured workflow explicitly includes the automated activities that support that triage.

So what is guaranteed is how quickly an alert becomes a classified incident. Not when you are told, and not when anything is contained.

Acknowledgement timing, investigation timing, containment activity and communication quality are all tracked and reported to you — but as operational metrics, not as contractual service levels. That is the honest shape of the contract, and it is exactly why the escalation path belongs in the order rather than in an assumption: agree in advance who is called, on which number, at what severity.

What no MDR contract commits to, ours included, is a containment clock. Containment depends on what is in scope, what permissions exist, and what the incident turns out to be. And when you compare our fifteen minutes against somebody else’s, the only question that makes two such numbers comparable is where each clock starts and stops. Ours starts when the incident is created and stops when it is classified.

You decide, once, at the start — not at three in the morning. During activation we agree a response profile that says what we may do on our own authority and what we must come to you for, and it is backed by Microsoft delegated administration that you grant and can revoke at any time. What is available depends on what is in scope: where Defender XDR is part of the picture, that includes quarantining an endpoint, removing a confirmed malicious file, allow- and deny-listing, and user actions such as revoking sessions, disabling an account or forcing a password reset where you have provisioned the role. Where the scope is Sentinel alone, the service detects and tells you — there is nothing to contain with, and we would rather say that at the outset than let you discover it during an incident.

A staffed security operations centre, 24 hours a day, seven days a week, every day of the year — reachable on a dedicated line, by people you have named in advance as authorised to speak to it, so an incident call is never held up establishing who is on the phone. Through the triage and response of a major incident you are in direct contact with the analysts working it rather than filing a ticket and waiting for it to move.

The structural answer is that you are notified after classification, not before it: an alert is triaged and established as a genuine incident, benign activity or a false positive first, and only the first category is escalated to you. Alerts are tuned continuously to your environment for the same reason. What we will not do is quote you a weekly ticket number — it depends entirely on your estate, your log sources and what is actually happening in your network, and any provider who gives you that figure before seeing your environment is guessing at it.

Yours, and it is worth being blunt because it changes the maths: Sentinel ingestion, Azure consumption, Log Analytics, and the Microsoft 365 and Defender licensing are all billed to you by Microsoft directly. We are not reselling your licences and there is no margin for us in your ingestion. What we do carry is the other side of it — log sources are reviewed and tuned against ingestion cost rather than volume for its own sake, and reduction analysis is available for as long as the service runs. It is the one part of this where our incentive and yours point the same way, and you should check that in any competing proposal.

Your side is enabling logging on the systems in scope, routing those logs to Sentinel, installing the collection agents, and granting the delegated Microsoft administration the service runs on. Log sources need to be onboarded and integrated within 30 days of go-live — that is a real deadline rather than a guideline, because a service monitoring half an estate gives you a false sense of coverage. We will not quote you an elapsed time to go-live from a document; it depends on how many sources you have and how quickly access is granted, and we would rather scope it with you than name a number we would then have to defend.

Partly, and the line matters more than most things on this page. Remote investigation and analyst time during the incident are included, without a cap on how many incidents — you are not metered for having a bad month. What is not included is digital forensics, post-incident root-cause work, on-site support, and the remediation and recovery itself: we give you the guidance and the actions to take, and performing them in your environment is yours. Forensics and full incident response are a separate engagement, which is why we sell an incident response retainer as its own service. The time to agree that is before you need it.

In your own Microsoft tenant. Logs are aggregated and stored in your Azure environment, and the service reaches into it rather than copying it out — so the data never leaves infrastructure you control and you can see exactly what is held. Our access is Microsoft delegated administration that you grant during onboarding and can withdraw without our cooperation. One responsibility sits with you and we would rather flag it than let it surprise you: obfuscating personal data and other protected information in the logs you forward is the client’s obligation, so it is worth deciding early what should be masked before it is ingested at all.

The size of the estate we watch and how much of it is in scope — how many endpoints, servers and identities, and whether we are covering Sentinel, Defender, or both together. Your Microsoft consumption is separate and billed by Microsoft, not by us, so the two move independently: adding a log source raises what Microsoft charges you for ingestion, and tuning it back down is part of what we do.