Choosing a Microsoft MSSP Without Getting Burned (SOC/SIEM)

All right class.

Too many companies hand their entire security operation to the first provider who can say "Sentinel" without choking. Six months later, the invoices are enormous, the SLA is decorative, and nobody can explain what the provider actually does all day. The analysts rotate every quarter, the detections are stale out of the box rules, and your "24/7 monitoring" turns out to be someone glancing at a dashboard between YouTube videos.

This is how you do it properly, staying inside the Microsoft ecosystem.

In this part one lesson, I will cover everything you need to sort out before you speak to a single provider: defining your scope, building your requirements, and writing an RFP (request for proposal) that filters out the time wasters. Lesson two covers evaluation questions, onboarding and making sure the whole thing actually works once you have chosen someone.

Scope First, or Everything Else Is Noise

Before you talk to a single vendor, sit down and answer these questions yourself.

What does your company actually need from an MSSP?

Do you want an external team that bolsters your internal function, or do you want to park almost everything with them while your people handle governance and escalation only? These are fundamentally different engagement models, and if you mix them up, you will end up paying for one and expecting the other.

If your team loves KQL and lives in Sentinel and Defender XDR every day, you probably want the augment model. If your "SOC" is one person who checks the portal between project meetings, you need a very different conversation.

What services are you actually buying?

SIEM architectural design, Sentinel workspace layout, data connector configuration and Azure Monitor log architecture? Ongoing rule tuning, threat hunting, incident triage and response inside Sentinel and Defender XDR? Or the extras like incident response, digital forensics, malware analysis and post incident review?

And do not skip over automation. In a modern Microsoft SOC, Logic Apps playbooks, Sentinel automation rules and enrichment pipelines are not optional extras. They are the difference between a SOC that functions and one where analysts drown in alerts they cannot process fast enough. Ask your MSSP if they are planning to use any, and how costly they are. Will the automation live in your environment or theirs? If you drop them in 3 years, are they going to delete the whole infrastructure? Can they create a new one for you if needed?

Spell it all out. If you expect them to reverse malware and run full IR, say so up front. If you just want them to ring you when a high severity Sentinel incident fires, say that instead. Nobody can price what you refuse to define.

What about threat hunting?

This is where most MSSP engagements quietly disappoint. A lot of providers will sell you "threat hunting" as part of their service, but what they actually deliver is alert triage. An analyst looks at the incidents Sentinel creates, investigates them, and closes or escalates. That is not hunting. That is the baseline job.

Real threat hunting means proactive work. Analysts form hypotheses based on current threat intelligence, writing KQL queries against your data to look for activity that no rule has flagged, and doing this on a regular cadence. Not once a year when someone remembers. Not only when a major vulnerability hits the news.

If you want hunting, define what that looks like. How many hours per month? Do they deliver written hunt reports? Do findings feed back into new analytics rules? If you leave this vague, you will get "we hunt when we have time," which means never, because triage always eats the day.

What are your log retention policies?

In 2025, you do not get to shrug at retention. Between privacy law, sector regulators, and contractual obligations, this is non negotiable.

Decide how long you need to keep Entra ID sign in logs, Sentinel incidents, Defender alerts and raw telemetry events. Work out which tables belong in the Analytics tier, which go to Data Lake, and which you do not need at all. Hand those numbers to the MSSP or ask them to help you out, so they can design retention and archive rules in the Log Analytics workspace that match reality, not guesswork.

If you do not have clear retention requirements yet, start defining them now. Tell the provider they will be locked in as part of the project. Do not let them design a workspace without this information or you will end up paying to store data nobody needs, or worse, deleting data a regulator will ask for.

What are your compliance requirements?

In a small company this is straightforward. You ask Bill or Sarah who handle compliance across your two offices and that is your answer.

In a global organisation with presence in fifty countries and fifty thousand staff, it is not that simple. You need someone to map which locations have data residency rules, which regulators care about logging, and which clients require specific certifications before they will even sign a contract. That might mean SOC 2 Type II, ISO 27001, local government frameworks and client contractual clauses, all stacking on top of each other.

Do not forget client driven compliance. Plenty of large customers will refuse to do business with you until you show a current ISO certificate, up to date audit reports, and working logging that covers their workloads. If the MSSP cannot support that, you have a problem before you even start.

Set SLAs like they actually matter, because they do.

This is where most people get lazy and regret it for years.

Say you want your initial response time for critical incidents to be within twenty minutes. That means from the moment a critical Sentinel incident is created, the MSSP needs to see it, triage it and contact you inside that window. They come back and say their minimum is thirty minutes, maybe longer out of hours.

You decide whether to accept that. If it genuinely is not good enough, keep pushing. You are the one carrying the risk when something goes wrong at 3 am on a bank holiday. Once you sign, these numbers become contractual obligations. Both sides will be measured against them. Do not treat SLA terms as decoration you never look at again. Ask them an open question on how they can provide SLA information, is it in a workbook in Sentinel? Monthly reports?

Turning Scope Into a Proper RFP

The RFP (request for proposal) is your chance to filter out providers who cannot read instructions, let alone run a SOC. Structure it deliberately.

Give them an introduction that actually tells them something

If you want a tailored solution, you have to give them something to tailor to.

Tell them what your business does, how many users you have, how many on premises servers exist, the number of Azure subscriptions, which Microsoft security products are already deployed and at what maturity level. If you withhold everything, do not then complain that the proposal is generic and vague. You cannot expect a realistic Sentinel cost model if you refuse to say how many data sources or workspaces are in scope.

If you are uncomfortable sharing details, get an NDA signed before the RFP goes out. That is normal. What is not normal is expecting a detailed proposal based on nothing.

Outline your needs in plain language

Explain what you expect them to do, technically and operationally. No ambiguity.

If you want them to ingest the most expensive data into the data lake say so. If you are migrating logs out of some ancient on premises SIEM and into Sentinel, write that down. If part of your data currently lives in AWS or Google Cloud and you expect them to integrate it into Sentinel using data connectors or custom ingestion, spell it out. The provider cannot tell you whether something is achievable if you never mentioned it existed.

Define scope and duration clearly

Write the project scope as if you were going to hand it to an internal engineer to build.

For a Microsoft environment, that means specifics. Number of Sentinel workspaces. Azure regions. Count of Windows servers, domain controllers, firewalls, SQL servers. Any Azure Arc connected machines. Current Sentinel deployment status. Number of Entra ID tenants. Approximate user count and licence mix, whether that is Microsoft 365 E5, E3 with security add ons, or a mess of both.

Also state how long you expect the engagement to last. A one year contract with options to extend? A three month build phase followed by a three year managed service? If you leave the duration vague, pricing will be equally vague.

Be brutal about technical requirements

This is where most projects quietly fail. Vague technical requirements leave room for interpretation, and that interpretation will always favour the provider, not you.

Write expectations clearly. All access to customer environments must use Azure Lighthouse for cross tenant management, keeping log data in customer owned subscriptions at all times. Native Microsoft connectors must be used for Microsoft sources before suggesting any third party collector.

Least privilege must be enforced everywhere. That means Sentinel, Defender XDR, Azure RBAC, the lot. This is not a nice to have. I have seen providers with read/write permissions across an entire Azure environment because someone ticked a box during onboarding and nobody questioned it. That is not a partnership, that is a liability.

Ask for documentation around Sentinel workspace architecture, retention configuration, and coverage. If they build it and cannot explain it, you own something you cannot maintain.

Require a detection coverage map

This deserves its own line in your technical requirements because it is the single best way to measure whether your MSSP is actually protecting you or just running whatever rules came in the Sentinel content hub.

Require them to map their analytics rules and detection logic to MITRE ATT&CK. Not a vague reference to "we align with MITRE." An actual matrix showing which techniques they detect, which data sources feed those detections, and where the gaps are. If they cannot produce this, they do not know what they are covering and neither will you.

This is not a one time exercise either. The coverage map should be a living document that gets updated as they build new rules, retire old ones, and onboard new data sources. It should be reviewed in your quarterly strategy sessions. Without it, you are flying blind and paying someone to fly blind with you.

When you see the map, you will probably find entire tactic columns with almost no coverage. That is normal and expected. Keep in mind that the generated MITRE may not cover the built-in detections from XDR and Defender for Cloud. What matters is that both you and the provider can see it, talk about it, and prioritise closing the gaps that matter most to your environment. A provider who resists this exercise is a provider who does not want you to see how thin their detection actually is.

Outline integration requirements realistically

Put everything you expect on the table, even if you think it might be difficult.

Need to migrate from Splunk or QRadar into Sentinel? Say that. Want Cisco Meraki firewall logs, Palo Alto syslog, or Fortinet data flowing into Sentinel? Say that. Running Darktrace and wondering whether those logs add value in Sentinel, or whether you are just ticking a box because someone in leadership likes the product name? Ask the provider directly. A good MSSP will tell you what is worth ingesting and what is just expensive noise.

If you have AWS accounts or Google Workspace and expect those logs in Sentinel, specify it. The provider needs to explain how they will achieve that, whether through native connectors, Azure Functions, or custom ingestion pipelines.

Define performance metrics

This is your catch all for every number you care about.

Initial response time by incident severity. Average time to resolve incidents. Average time to escalate between analyst tiers. Percentage of incidents classified as true positive. Time to onboard new data sources or deploy new Sentinel analytics rules. Frequency of detection engineering reviews. Number of proactive threat hunts conducted per quarter and their outcomes.

Always ask about those to have a clear picture of what to expect.

Desired qualifications and accreditations

Decide what actually matters to your environment.

Maybe you want all SOC analysts to hold SC-200 (Microsoft Security Operations Analyst). Maybe you expect architects to carry SC-100 (Cybersecurity Architect) or AZ-500 (Azure Security Engineer Associate). Perhaps you require the MSSP's own SOC to hold compliance certifications like ISO 27001 or SOC 2 Type II.

Be specific. If you say nothing, you will get whatever they happen to have on the bench that week. And if their "senior analyst" turns out to be someone who passed SC-900 last month and nothing else, that is on you for not asking.

Ask for a detailed cost proposal

You want the bottom line laid out, not hidden behind smoke and mirrors.

Ask for a breakdown of build costs, monthly monitoring fees, Sentinel ingestion management, any surcharge for 24/7 coverage, and any add ons for hunting, IR or forensics. Ask how they handle cost if your Sentinel ingestion spikes. Ask whether there are penalties for early termination.

If the pricing model looks like it was designed to confuse you, it probably was. Walk away.

Important thing to mention here, if you have no idea how many logs you have, what's the ingestion rate, events per second? events per day? Don't expect MSSP to know this for you; they can provide an estimate, but if you have a server that is generating 100x more logs because you installed bloatware on it, that's on you, at least until they can help you cut down the noise.

Set timeframes and next steps

Publish clear dates for the entire process.

Date the RFP is released. Last day for vendor questions. Date you will send answers back. Proposal submission deadline. Date you will shortlist. Expected date for proof of concept decisions and final contract award.

If you leave this open ended, the process will drag on for months and everyone loses momentum.

Response format and extras

Tell them exactly who to send responses to, in what format, and whether you expect supporting materials. Do you want example incident reports? Sample escalation messages? Idea on what workbooks will cover?

If a provider cannot follow basic instructions about how to submit an RFP response, picture what they will do with change control and incident handling.

In lesson 2, we get into the evaluation questions that actually reveal whether a provider can do the job, the onboarding process that stops things falling apart on day one, and the pre-flight checklist you should run through before you send that first email.

Class dismissed