Most small and medium organisations know they should be monitoring for attacks, and most know they cannot staff a security operations centre themselves. The market's answer is a crowded field of managed services: managed detection and response (MDR), managed SOC, managed SIEM, managed XDR. The labels overlap, the marketing is similar, and the differences only become clear when something goes wrong at an inconvenient time.
This guide is for UK SMEs and mid-market organisations evaluating these services. It explains what the terms usually mean, which questions separate strong providers from weak ones, and how to avoid paying for alerts nobody acts on.
MDR, managed SOC and managed SIEM: what the terms usually mean
- Managed SIEM: the provider runs a security information and event management platform for you, collecting and correlating logs. Detection and investigation may be limited; you may receive alerts and be expected to act on them yourself.
- Managed detection and response (MDR): the provider detects, investigates and responds to threats, usually centred on endpoint telemetry from an EDR product, and increasingly identity and cloud signals too. Response typically includes containment actions such as isolating a device or disabling an account.
- Managed SOC: a broader service in which the provider operates security monitoring as an extension of your team, often including detection engineering, threat hunting, vulnerability insight and reporting.
Because providers use these terms differently, compare services on what they do, not what they are called.
Question 1: What is actually monitored?
Coverage determines what can be detected. The NCSC's guidance on logging for security purposes emphasises collecting the logs that help you detect and investigate incidents, not simply everything. For most SMEs the priority sources are:
- Endpoint detection and response telemetry from laptops and servers.
- Identity: sign-in and audit logs from Entra ID or your identity provider, which is where account takeover appears.
- Email security events, since phishing remains the most common entry point.
- Cloud control plane logs, such as Microsoft 365 audit logs, Azure Activity Logs and AWS CloudTrail.
- Firewall, VPN and remote access logs.
Ask exactly which sources are included in the price, which cost extra, and whether the provider builds detections for each or merely stores the data.
Question 2: Who can take action, and how fast?
Detection without response is a notification service. Ask what containment actions the provider is authorised to take without your approval, such as isolating a device, revoking sessions or disabling an account, and what requires a call to you first. Agree this in writing before an incident. Ask how response times are defined in the contract, what hours are covered by analysts rather than automation, and what happens outside those hours. Compare the contractual commitments, not the brochure.
Contract questions worth asking
- Which log sources are included, and which incur extra cost?
- Which actions can you take without our approval?
- How are response times defined, measured and reported?
- Who owns the detection rules and the data if we leave?
- Is incident response included, or a separate engagement?
- Where is our data stored and processed?
Question 3: How good are the detections?
Ask how detections are developed and tested, how they map to adversary techniques in MITRE ATT&CK, and how often they are tuned to your environment. Good providers can explain how they reduce false positives without suppressing real attacks, and will share examples of detections they have written for environments like yours.
Question 4: What will you receive each month?
Reporting should show coverage, notable incidents and what was done, trends and recommendations. Avoid reports that only count alerts. A falling alert count can mean better security or broken log collection. Reports that can be mapped to compliance frameworks are especially useful if you are pursuing ISO 27001 or must evidence monitoring to customers. PyraLink™ Prove can add signed cloud configuration evidence alongside them.
Question 5: Who owns what if you leave?
If the service runs on the provider's own platform, you may lose historical logs and detection content when the contract ends. If it runs on a platform in your own tenant, such as Microsoft Sentinel in your Azure subscription, you keep the data and the rules. That model also gives you direct control over cost, which matters because log ingestion is usually the largest variable expense. Our guide to reducing Microsoft Sentinel ingestion costs covers how to manage it.
Getting ready for MDR
Providers can only detect what they can see. Before onboarding, make sure EDR is deployed to every endpoint and server, MFA and centralised identity are in place, cloud audit logging is enabled, and you have an incident response plan with named decision-makers. Strong identity controls based on zero trust principles reduce the number of incidents in the first place. Remember that if an incident involves personal data, you may need to notify the ICO within 72 hours of becoming aware of it, so make sure your provider's escalation fits that timeline.
Red flags when comparing providers
A few warning signs come up repeatedly. Be cautious of pricing that looks low because it covers only a narrow set of log sources, with everything else charged as an extra once you are committed. Be wary of response commitments that apply to "acknowledgement" rather than investigation or containment, since an automated acknowledgement within minutes says nothing about when a human will look at the alert. Ask how many customers each analyst supports and how the provider handles a surge of incidents across many customers at once, such as during a widely exploited vulnerability.
Look closely at onboarding. A provider that promises full coverage in a few days without asking detailed questions about your environment is unlikely to have tuned detections for it. Good onboarding includes a review of log sources, identification of critical assets and privileged accounts, agreement on escalation contacts, and a period of tuning to reduce false positives.
Finally, ask for references from organisations of a similar size and sector, and ask those references specifically about the last real incident the provider handled for them. How the provider communicated during a stressful event tells you more than any sales presentation.
How Pyralink helps
Pyralink is a product company and does not provide a managed SOC or MDR service. Its product works alongside the provider you choose: PyraLink™ Prove adds read-only cloud configuration evidence. Keeping the SIEM in your own tenant means the data and detection content stay with you if you change provider.
Frequently asked questions
What is managed detection and response?
Managed detection and response (MDR) is a service in which a provider monitors your environment, investigates suspicious activity and takes containment actions, typically using endpoint, identity and cloud telemetry.
What is the difference between MDR and a managed SOC?
The terms overlap. MDR usually focuses on detecting and responding to threats, often centred on endpoints. A managed SOC is often broader, including detection engineering, threat hunting and reporting. Compare services on what they actually deliver.
Do SMEs need a SIEM?
Not always. Many SMEs get good coverage from EDR plus identity and cloud logs through an MDR service. A SIEM becomes valuable when you need to correlate many sources, retain logs for compliance or run custom detections.
Which logs should a small business monitor first?
Endpoint detection and response telemetry, identity sign-in and audit logs, email security events and cloud audit logs such as Microsoft 365 and AWS CloudTrail are the usual priorities.
Should the SIEM be in our tenant or the provider's?
Running it in your own tenant means you keep the data and detection content if you change provider, and you have direct visibility of cost.
Sources: NCSC: Introduction to logging for security purposes; NCSC: Incident management; MITRE ATT&CK; ICO: Personal data breaches, a guide.